0

The CSRF synchronized token makes sense up to certain point. Can someone explain the rest in a childish manner to where I can understand it.

When a user logs in they are given a session ID and a CSRF. The session ID is stored in session cookies and the CSRF token only stored on the page, preferably in a hidden field. When a user submits a request that requires special privileges the CSRF token is sent with it. The server verifies that is the user and commits the action.

Okay here's where I'm having the problem. If a user gets his session id stolen along with any other identification, say from a man-in-the-middle attack, which doesn't need XSS. Wouldn't the malicious user be given the same CSRF token that was given to the session to that user?

  • Ignoring headers answers for prevention please *
  • Consider learning about the same origin policy and web security in general. Understanding CSRF is easy, if you understand the basis of web security. – rook Oct 18 '16 at 22:59
0

Though vulnerabilities can be chained, we need to look at vulnerabilities from an independent perspective too. Fixes for one vulnerability might help in fixing another one, but that is not usually the case.

CSRF is the attack in which an attacker manipulates the inherent browser-user trust. Anyone with a valid session should also have a valid CSRF token because that's how the application is supposed to work. Whether or not the user stole somebody else's session token, doesn't matter much to the application here. There is no way for the server to identify if the session has been stolen or not either.

So apparently from an application's perspective, it is using session id to identify and maintain session. A stolen session id doesn't imply session change and hence the attacker will get a valid CSRF token.

But if the CSRF token is not valid, it can understand that the request originated Cross Site and that it is forged.

1

CSRF tokens aren't a defense against other users logging into their account. CSRF tokens are a defense against CSRF attacks only. If anyone logs into an account (including an attacker), then they should get the CSRF token (along with all of the other content that's normally served to the user).

  • Then how does a server verify that is the action that user wants to take? If a malicious user is able to emulate the session then what is to prevent the malicious user from committing an unwanted action? – White Lotus Oct 18 '16 at 21:56
  • @WhiteLotus it doesn't. CSRF tokens prevent sessions from being emulated by CSRF; they don't protect the user if the session is already stolen in some other way - you should look for ways to prevent that in the first place, MITM attacks shouldn't 'just happen' over proper https. – Peteris Oct 18 '16 at 21:58
  • CSRF attacks are generally made by attackers that can't see the response the user receives from the server. CSRF attacks are different than MITM attacks. – Macil Oct 18 '16 at 22:02
  • @Peteris Thanks! That is the answer I was looking for. Put it in the answers so I can accept it. – White Lotus Oct 18 '16 at 22:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.