CSRF – Cross Site Request Forgery

Background: What is a CSRF (Cross site request forgery)?

The concept is best explained with an example. Say there is a website (MyBank) with some functionality to transfer money. Say a user logins into the website and transfers money to their friend B. The user then looks at another site (MyFavoriteTeam).

Unfortunately the other site (MyFavoriteTeam) includes a malicious script added by a hacker that posts a request to MyBank to transfer money to stranger C. As the user is logged on to MyBank already,  the request arrives with the correct MyBank authorisation cookies (issued when the user logged on to MyBank earlier) and the Money is transferred. Thus Cross site request forgery. This reuse of cookies is just how browsers work.

Owasp describes the problem well with html added to the other site something like below
<img src=”http://MyBank.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#&#8221; width=”0″ height=”0″ />

In this approach a link to an image is used to send a get request to transfer money. The other site with the image html has been hacked to add the image html or it allows a link to an image to be added (a user profile picture for example). Either way the malacious html will fire a request to perform the action.

Obviously it is quite difficult to engineer this situation. You need someone to be logged in to a site (and then forget to logout or there to be a bug in the logout) and then go to another site with the malacious html or javascript. This can be achieved via volume -hit lots of users and hopefully one is logged in to the site in question – or a more targeted approach. One targeted approach is to add a comment to the MyBank site telling people to visit a site containing the malicious code. (Probably why banking sites dont allow comments among other reasons)

There are a couple of immediate ways to make this more difficult for the hacker. If the banking site has a logout functionality the logout functionality can invalidate the cookie. Also the mybank authorisation cookies can be set to sensible timeout values. Both these points try to limit the chances of the authorisation cookies still being in the background when a malicious script runs. Thirdly the MyBank site could include a requirement to enter a password or a gotcha on critical functionality in an effort to prevent the script from working automatically.

The hack normally works by using the ambient authorisation i.e. the MyBank authorisation cookies that are floating in the background (held by the browser). The points above attempt to disrupt this by reducing the likely hood of the ambient authorisation being available (sensible timeout and log out). Another approach is not rely purely on the ambient authorisation this can be achieved by asking for a password or a even a capcha

From the server this hack is difficult to detect as looks like valid request. As it was in fact sent by the user’s browser & the user’s ip etc. In fact if money is transferred via an approach like this it is difficult to decide if the request was initiated by the user themselves or not. luckily the problem can be largely prevented via the use of tokens.

The standard way to do this is to add to your view within the form element the following code @Html.AntiForgeryToken() something like below

@using (Html.BeginForm()) {
@Html.AntiForgeryToken()

and then mark up your action with the [ValidateAntiForgeryToken] attribute, something like below

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Edit(MyClass myClass)

{

The @html.AntiForgeryToken() injects a token on the page in a hidden field. When a post is fired the token is passed in the request. The controller then checks for the token and rejects the request if the token missing\incorrect.

Essentially the code above makes sure the form was issued by the MyBank sitein the first place.

Note any XSS flaws (and any SQL injection flaws which could allow XSS) in your website can be used to bypass the CRSF thus negating the whole approach.

For critical functions asking for a password or a capcha etc can also reduce the risk of CSRF at some inconvience to the user.

In summary CSRF can easily be negated using the built in anti forgery tools available in ASP.NET MVC. Please note other technologies like HTTPS\SSL do not help with this problem as they simply secure the forged request. HTTS\SSL will help protect the data when the page is requested and the information posted back they just wont prevent the forged request from firing.

2 thoughts on “CSRF – Cross Site Request Forgery

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s