Why bother requiring CSRF token on POST requests?

Question

My understanding is that CSRF prevents an attacker using an tag to get the victim\'s browser to send a request that would be authenticated using the

Answer 1

The attacker can host a form on their own site, but it does not require the form to be submitted by the user. They can use JavaScript to do this:

<form method="post" action="http://www.example.com/executeAction">
    <input type="hidden" name="action" value="deleteAllUsers">
</form>

<script>document.forms[0].submit()</script>

IFrame injection is more of a XSS vulnerability. A XSS vulnerability is more serious than a CSRF one because more damage can be done and it will always override any CSRF protection you have. Make sure you are always correctly encoding output for the context that the output is in (e.g. encode for HTML or for JavaScript as appropriate).

Check out the Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet - their best recommendation is to use the Synchronizer Token Pattern which seems similar to the link in your answer but can work in combination with cookies.

Also, here's a link to the XSS (Cross Site Scripting) Prevention Cheat Sheet.

Answer 2

Cross Site Request Forgery is when a site (let's say evil.example.com) can force a visiting user to make requests to another site (let's say example.com). It's not really forcing a user since embedding a image that (HTTP GET request) or POST request via form submission or javascript is not that difficult.

1. You should not make state or data changes via HTTP GET requests. img tags (get request) shouldn't be able to make any kind of change what so ever. If you allow this ... stop it. :)

2. POST requests need to contain a value that is not guessable by a remote attacker. Typically this is a per request random value.

So yes, CSRF is a a demonstrated, known vulnerability that you should bother protecting against.

Answer 3

Having done some further investigation:

It's possible for the attacker to host a <form> on their own site which submits to the target site (your site). All they need to do is get the victim to submit this form and it'll be submitted with their cookies and potentially their authentication.

It's also possible for the attacker to inject an <iframe> into your site, which would then be able to display this malicious <form>.

I'm thinking that a token-based approach is a better solution for my use case.