Cross-Site Request Forgery (CSRF)
What is CSRF?
Cross-site request forgery (CSRF – pronounced sea-surf) is a technique which allows an attacker to carry out operations on a user’s website account without having direct access to the account. By making the user’s browser request that actions be carried out on the user’s account, the attacker can convince the website that it is the user who is making the request. The website will allow the account operations despite the user never having authorised those actions. The attack is known by several other names including Session Riding, One-Click Attacks, Cross Site Reference Forgery, Hostile Linking, and Automation Attack.What makes a site vulnerable to CSRF?
CSRF typically affects sites which store the user’s session information in a cookie. Each time the user requests a page from the website this cookie data is sent along with the request. On seeing the user’s session id the website recognises that the user is logged in and gives him access to his account. This basic mechanism is, by default, vulnerable to CSRF. If the attacker can persuade the user to visit a webpage controlled by the attacker, while still logged into the vulnerable site, the attacker can get the user’s browser to submit a request to the vulnerable site (via JavaScript, a disguised form, etc). Since this request comes from the user’s browser, the website will enact the associated action on the user’s account.CSRF attacks do not always require a user to be logged in to some site and therefore have session cookies to submit. More generally, the user just needs to have some form of access that the attacker doesn't. For instance, the user may have access to an intranet-based website, which the attacker doesn't.
Impact of CSRF attacks
CSRF allows an attacker to carry out almost any operation on a user’s account which a user could himself have carried out. This can include transferring money, using stored credit card details, changing private details, etc. The attacker may also be able to change the user’s password to gain ongoing control of the user’s account. Alternatively, the attacker could delete the account, destroying the user’s data and access. CSRF attacks can also mess up logs as any action taken as the result of a CSRF attack will appear to have been carried out by the victim. This makes it hard to discern what actions were the result of the attack and which were the result of legitimate user activity.Example of a CSRF attack
Suppose the vulnerable site is a web-based email application. The attacker can send the user a link by email to a webpage controlled by the attacker. If the user clicks on the link he will be taken to the webpage while still logged into the email application. This webpage has embedded JavaScript which, when run by the user’s browser, will submit a form to the email client which mimics the email client’s own password change form. In doing so, the attacker can change the user’s password. Now the attacker will be able to log into the account and the user won’t, giving the attacker full and exclusive control over the user’s account.Preventing CSRF attacks
CSRF occurs when information is submitted to a vulnerable site without the user’s consent. To prevent this it is necessary to ensure that the user’s consent is first given to any information submitted. One way to do this is to add a hidden one-time token to each form issued by the site. Then when a filled out form is submitted from the user’s browser, the website can check that the form has a valid token. This check must also check that the user submitting the token is the same user that the token was issued to, or else the attacker could create an account, get a token and then use it against the user.Since the attacker does not initially have access to the user’s account he will not know a valid token, and any form he tries to cause the user to submit will fail. On the other hand, any page visited by the logged in user will issue a valid token which, when the user returns the form, will be accepted by the website and the appropriate actions carried out. Note that this defence will not work if the site is vulnerable to Cross-Site Scripting attacks as the attacker will be able dynamically capture the token and include it in the request. The token can be valid for a particular form, page or user.
CSRF attacks can also be prevented by double-submitting cookies (by javascript, for example) to a website. Normally the browser will send the cookie to the website as part of the request. The attacker is able to trick the user’s browser into sending this cookie along with a malicious request. If, however, the site requires that the cookie be sent not just with the form, but also within the form (i.e. as part of the form data), the attacker will not be able to submit a valid form, since cross-browser rules prevent the attacker from reading the user’s cookie (which he would need to do to include it in the form). Those same rules allow the user to read the cookie and include it in a form filled out by the user. In this way, the website can distinguish between valid users and attackers, and accept and reject requests accordingly.