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.
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.
The fix is: 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.
Example (fixed code):
- fixed application
- fixed, view the page source and then go back and take a look at the link above (fixed application).
all source code