CSRF and defence mechanisms

Question

I was reading some material about the defense mechanisms used to protect against CSRF attacks. I think I've a question about the one based on a secure token.

As far as I know, a web application should be designed to include a secret token, which would block a CSRF attempt. This would work simply because the attacker wouldn’t know such token, hence s/he could not add it into the malicious redirect (I read a nice old summary from a senior user in the forum).

The bit I’m still struggling to grasp is how this works:

• If I am indeed logged into that website, what would prevent my browser from adding this secret token to the malicious redirect? (Hopefully, the answer is that it does not, because of the very nature of this token, but I'm just missing how it works)

• If I am not logged into that website, the attack would fail anyway, right? (Unless of course a malware has infected the machine and will wake up a “dormant” CSRF attack as soon as it has detected that the target URL has been requested by the user. That’s however beyond the scope of my question)

Answer 1

In short, it's because websites can send data by making POST request to other websites, but they cannot read data from other websites.

Let's forget about CORS (a way to explicitly allow sharing data between different domains anyway), and let's say A and B are two unrelated websites. A can make a POST request to B, sending data and performing actions. But A cannot read the content of B in any way (frames, Ajax requests, etc. won't work). So tokens provide a solution to CSRF because in order for A to make a successful POST request to B, the secret value of the token must be known. And there's no way to know it, unless you are on B. Only B knows the right value for your session.

Answer 2

...the one based on a secure token.

I assume you are talking about what OWASP calls "the synchronizer token pattern".

If I am indeed logged into that website, what would prevent my browser from adding this secret token to the malicious redirect?

What is important here is that the token is not stored in a cookie. The server gives the token to the client in a HTTP header or the HTTP body, but not in a cookie.

While cookies are sent automatically even in cross domain requests, there is no way for an attacker to know the value of the token and include it in the request. The browser knows the value, but due to the same origin policy, it will not tell the attacker.

If I am not logged into that website, the attack would fail anyway, right?

Usually, yes. In most cases CSRF relies on the victim already being logged in. But there are exceptions:

• If a service is only accepting requests from within a specific IP range, a CSRF attack against a user in that range can bypass that restriction.
• If the login form does not have CSRF protection, you can do "log in CSRF", where the attacker tricks the victim into loggin in as the attacker.

Answer 3

To answer your two questions,

1. There is nothing a browser can do to prevent an attacker from inserting the secret token into the malicious attack, given that the attacker knows the secret token. This is actually necessary for the website to function at all. It’s crucial for the secret token to remain secure, such as by storing it in a cookie, since attackers can’t read cookies for another domain. If the secret token is presented to the server only in the form of an HTTP header, I believe CORS would make it impossible for an attacker to insert a known secret token into a request, since it would be cross-origin, but I wouldn’t rely on only this fact.

2. If your attacker can reach the same state as you currently are, the attack would accomplish nothing. The attack works if the attacker cannot reach the same state you are in, such as being logged in or being on a certain IP address — this is application-specific. As you described, if you are logged out on the browser you are attacked on, the attack shouldn’t work because you lack the necessary credentials. If you could, it would be a serious authentication bypass issue.