A CSRF attack forces a victim’s browser, with an established session, to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
This is an example of the confused deputy problem, where a program is convinced by
another program to abuse its authority.
- Authentication: Identify who you are
- Authorization: What you are allowed to do
Example
- vulnerable application
- exploit, view the page source and then go back and take a look at the link above (vulnerable application).
Note: When you visit the exploit link above, you are going to exploit/xsrf.html at www.cs.toronto.edu, not cs.utm.utoronto.ca. Part of the content
of exploit/xsrf.html is a 1px by 1px image with source from secrets.php which is at cs.utm.utoronto.ca. Take a look at the page source for
exploit above to see this. The problem is that your browser will send all cookies to secrets.php to satisfy the image request,
even though the originator of the request was www.cs.toronto.edu. To sum up, www.cs.toronto.edu is forcing your browser to make a valid
request to secrets.php at cs.utm.utoronto.ca (another website). So the malicious www.cs.toronto.edu is causing your browser to
perform an operation you did not intend on performing, adding the secret crossSiteRequestForgery to your list of secrets.
- secrets.php source
Fix
- Create a random page token, store it in the session, include it in all forms,
as a hidden variable (for example), and verify it on each submit.
That is, the server accepts submits from known outstanding forms.
Bonus: This also fixes the browser back button problem.
- Don't use methods that do not respect the Same Origin Policy. For example,
POST forms are supposed to respect the SOP, so make sure that the server side only
accepts POST requests for updating information server side.