about CSRF on form submit [duplicate]

Question

I'm surely missing something in the picture of how CSRF attacks and protections are working.

My understanding in a form-submit scenery is the protection rely on a unpredictable token, someway is assumed the attacker can't get the token, why?

If the attacker is good enough to make me submit a form (as mentioned by OWASP) what would prevent him from getting the token before submitting?

There's a limit on javascript size/syntax that can be injected or is just the assumption I'm using a modern browser with Same-Origin Policy, what am I not seeing?

edit

My doubt, if I'm an attacker and I can inject javascript in the user form, why I can't get (using ajax) the form with the secret token, extract and inject the token in the form to be submitted?

edit 2

Forgive me for being pedantic but I'm trying to use CSRF protection on a php server and I may setup it wrong if I don't understand.

Regarding the OWASP's POST scenario example with submit onload, evil.com is the site the attacked user is visiting right? It will fire a post submit to the targetSite.com, the javasript onload in the example is simple but it could have been complex using a get of the form with the secret token before submitting, is that right?

If this is the case, is just the Same-Origin-Policy protecting the attacked user?

Answer 1

The reason that sites are able to impersonate users performing actions is because browsers will willingly submit a HTML <form> to any other domain specified using the action attribute without concern the origins being the same or any other restrictions provided by the target domain. The original domain has no way to read what was received by the user or whether the request was successful. The original domain is simply sending the user off to the target domain to perform one specific action.*

The reason that this CSRF attack does not work when using a token is because the user also sends cookies relevant to the target domain with each request. The original domain has no way to read these because cookies do not work cross-domain except in certain cases where the target domain is showing relation to the other. Therefore, it should not be able to reliably predict what the token on the target domain is.

All the target domain needs to do is check that the value sent in the request matches the cookie sent.

<sup>* original domain - domain that forces a user to send the POST/GET request
* target domain - domain receives the request and "owns" the CSRF token cookie.</sup>

---

The original domain has no way to view the token because any request for it would fail:

1. If the original domain requested it using PHP, the target domain should show a totally irrelevant cookie that is meant for that specific "user" (the original domain server, not the attacked user).
2. If the original domain tries to read the cookie, the browser should only show the cookies relevant to the original domain, eliminating the possibility of reading a cookie from another domain.
3. If the original domain requested a page using JavaScript, the browser should reject it because cross-domain ajax requests are not allowed (assuming the target domain does not explicitly allow it).

Answer 2

If the attacker is good enough to make me submit a form (as mentioned by OWASP) what would prevent him from getting the token before submitting?

The only skill an attacker needs to have is the ability to write HTML and javascript and know what the request they are trying to attack looks like. These are all things that are easily accessible and are not secret in any way.

So your assumption that the ability to create a form somehow means they can predict random tokens is incorrect.

Each token is unique to an authenticated user and unless there is another vulnerability, there isn't a way to figure out what that token is.

Based on how your question is phrased I'm not sure you have a full grasp of how CSRF works. This isn't meant as an insult - it can be a difficult concept to grasp initially.

My suggestion would be to create a form that is vulnerable to this type of attack and then execute an attack against it. This is an excellent way to get a thorough understanding of how this attack works. Once you do this - I suspect you will understand this answer better.

Cheers!

UPDATE:

It seems like you might be assuming that CSRF and XSS are the same thing. Just to clarify - in a site with only a CSRF vulnerability, a malicious user cannot insert any javascript. So there is no way to use javascript to get the token. If a site has an XSS vulnerability - then there is no need to execute a CSRF attack, because it would be much easier to simply inject javascript that does what you want. Also - a CSRF is a "one way" attack, meaning you can send a request as someone, but you can't read the result. Does this make sense?

UPDATE 2:

regarding your comment:

Thanks for clarifying, I was looking at the OWASP page linked in the question, section POST scenario, the submit onload, isn't that a CSRF attack with javascript injection?

Ahh - I see your confusion. No, the javascript they are showing is on the site controlled by the attacker. So if the attacker controls evil.com the javascript would be on there, and it is simply used to launch an HTTP request to targetSite.com using a users existing session. CSRF is an attack on existing sessions that takes place at the HTTP request level. It might use javascript to launch this attack, but the attack is still an HTTP request.

Answer 3

I'm not an expert on CSRF (please comment if I have misconceptions), but from wikipedia:

Under the [same-origin policy], a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number.

A simplified example is: lets say you have 3 tabs open in your browser which have loaded scripts from three sources: 1.aaa.com, 2.aaa.com and www.bbb.com. Your browser, under the same-origin policy (SOP), will allow the scripts from 1.aaa.com and 2.aaa.com to read and write data each other's data. This is how facebook stays logged in across all your tabs (even on non-facebook pages, cause the embedded facebook scripts are dynamically loaded from *.facebook.com, and therefore have the same origin).

However, a browser that implements SOP will prevent scripts from www.bbb.com from being able to read data meant for the *.aaa.com scripts. This prevents a malicious script from seeing that random token that another script has been assigned. SOP does not block writes, so a malicious script can still send requests claiming to be another script, but unless it can guess the random token, that request will be ignored.

I agree that the system is a little mind-warpy, but it does work.

Answer 4

Without the token check, the attacker wouldn't even need to inject javascript.

For example, they create a form on https://evil.example/ that submits to an action at https://target.example/. Instead of injecting javascript on the target site, they can just place it directly on the site they control and trick you to visit that. The POST request will still include target.example's cookies. If it doesn't check for a token, then the form submission will be accepted just as if it had come directly from target.example itself.

However, if there is a token check, evil.example can't obtain the token because of same-origin policy. So they would need an additional vulnerability on the target site. For example XSS would allow the attacker to retrieve the token via AJAX.