Cross-Site Request Forgery (CSRF) Vulnerabilities

Introduction to cookies and user authentication

Cross-site request forgery (CSRF) vulnerabilities are designed to take actions on a website on behalf of an authenticated user. Accomplishing this requires making a request to a particular website while the user is authenticated to it.

Luckily for hackers, a user’s session on a website is no longer limited to the time when they have the tab open. In the name of increased convenience, websites have the option to “keep me signed in”. For a set period of time after a user authenticates to a site by entering their credentials, they will be allowed in without needing to authenticate.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

This works because of cookies. When the user authenticates to a site and logs in with their credentials, the site saves a file on their system containing session information within it. The user’s browser will automatically include this cookie information in future requests to the site until the cookie expires or is deleted. This use of cookies makes CSRF attacks possible.

Cross-site request forgery vulnerabilities

While cookies are essential to a successful CSRF attack, they are not the only requirement. The attacker also needs the user to have an account on a site that performs important actions (i.e., ones that can benefit the attacker in some way) by using HTTP requests with important information contained within the HTTP request itself (via HTTP headers, verbs or a POST request). These pages should take an action with no user interaction required; visiting the page should be enough.

URLs have the ability to use verbs to pass additional information to a site. A verb, in this context, is a set of key-value pairs that appear after a question mark in the URL. For example, the URL https://www.mybank.com?uname=user&pass=Password would connect to mybank.com and make the values of uname and pass available to the target page.

If a website contains a page that is designed to take some action without user interaction, then an attacker can exploit it using a CSRF attack as shown above. On another web page, the attacker can embed something that would result in a browser making an additional request (image, ad, iframe and so on). This request would point to the desired page and since the user’s cookies would be automatically included in the request, should be successful since the user is authenticated. As a result, the target page would perform the desired action without the user’s knowledge.

Mitigating CSRF vulnerabilities

CSRF attacks occur completely on the client-side. While a server may provide content that includes the malicious link or perform an action in response to a request generated during a CSRF attack, all malicious activity occurs within the client’s browser.

However, this doesn’t mean that it is impossible to protect against CSRF attacks on the server-side. Two options are the use of randomized tokens and automated session timeouts

Random tokens

CSRF attacks work because an attacker can generate a completely legitimate request for a particular page and have it be executed within a user’s browser. However, these requests usually need to be generated in advance and have little configurability.

A common mitigation to CSRF attacks is to include a randomized token in each request and response. This token is generated by the server and included in the user’s requests to the site. If the token does not match the one expected by the server, then a request is rejected.

This prevents a CSRF attacker from generating a valid request for a site. Without the knowledge of the correct token to use, it is impossible to generate a request that includes it. As a result, attempts to exploit a site potentially vulnerable to CSRF attacks are unsuccessful.

Automated session timeouts

CSRF attacks rely upon the fact that a user is authenticated to a particular site. Any functionality of value to an attacker must only be accessible to an authenticated user. Otherwise, the attacker could visit the site and perform the desired actions directly.

Cookies extend user sessions, increasing both the usability of a site and its vulnerability to CSRF attacks. A good balance of usability and security would be to allow most passive functionality on a site (like viewing account balances) without authentication but require re-authentication or some user interaction for active functionality (like performing a bank transfer). Since a CSRF attacker never sees the CSRF response, they could not take this follow-up action, even if it is just clicking an “are you sure?” button.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

Sources

1. All You Need To Know About Cross-Site Request Forgery (CSRF), darknet.org.uk
2. Cross Site Request Forgery (CSRF), OWASP
3. Cross-Site Request Forgery Prevention Cheat Sheet, OWASP Cheat Sheet Series