- Exploits browser’s trust relationship with a website (e.g., an existing login)
- local intranet website (home router admin, …)
- banking or email site user is logged into
- browser is authorised to connect here
- Attacker triggers malicious action
- get user to open malicious link
- browser undertakes action on target site on behalf of authorised user
Question
How does CSRF differ from XSS ?
| Feature | CSRF | XSS |
|---|---|---|
| Targets | Server actions by authenticated users | Client/browser of any user |
| Attack Vector | Malicious request via victim’s browser | Malicious script in a web page |
| Requires login | Yes (exploits authenticated sessions) | No (depends on injection) |
| Protection Methods | CSRF tokens, SameSite cookies | Input sanitization, CSP, escaping |
Example of CSRF
Alice is logged in to the (hypothetical) GeeMail web mail system. She sends an email with this form :
<form
action="http://geemail.com/send_email.htm"
method="GET">
Recipient’s Email address: <input
type="text" name="to">
Subject: <input type="text" name="subject">
Message: <textarea name="msg"></textarea>
<input type="submit" value="Send Email">
</form>Which sends a request like this
http://geemail.com/send_email.htm?
to=bob%40example.com&subject=hello&msg=What%27s+the+status+of+that+proposal%3F
Now Mallory just needs Alice to visit a site which loads an image link, e.g., by putting a fake image on his own blog:
<img src="http://geemail.com/send_email.htm?
to=charliegeemail.com&subject=Hi&msg=My+
email+address+has+been+stolen">and Alice’s browser will send an Email!
CSRF : Protection
- Do not use GET for any (sensitive) state change, but not enough.
- Use a framework that has built-in protection
- Using a double cookie trick
- Set a secure secret session ID in a cookie
- Submit it in cookie and hidden field on form
- Server-side check if fields are identical
- Use a special CSRF token in POST
- Secure random number (challenge) for each login.
- Send this with POST and check server-side.
- Using a double cookie trick