2

Let's say that the website example.com has CSRF protection. They send a CSRF token in a custom header and in hidden input fields.

For example to add a new folder, your http request needs to contain CSRF token. What I've observed is that if you make the same request, with CSRF token but withou a session cookie it still works.

Should it works that way, that I can create a folder without session cookie, but solely with CSRF token?

|improve this question
  • Welcome to infosec.se. Any chance you could edit your question and reword it to make it a bit clearer what you're asking? – SilverlightFox Feb 7 '15 at 16:19
  • Absolutely. give me 2 minutes. – user67899 Feb 7 '15 at 16:22
2

Generally speaking, no.

CSRF protection and session authentication are typically supposed to be separate concepts entirely. The responsibility of a CSRF token is supposed to be a one-time key for a request - nothing more, while a session ID or session token is supposed to merely identify a user that has permission to perform the action in the first place.

You should have both in place unless the CSRF token holds both responsibilities somehow (which honestly, would indicate someone tried to be too clever with their security design, and failed).

|improve this answer
1

An interesting one. If the CSRF token identifies the user as well, then I can't see it being a vulnerability in itself. Some systems can work without cookies (although you mention this one is designed to work with cookies) and can pass around an auth token in a hidden form field that is used as both a session identifier and an anti-CSRF token.

In your case, as the system does use cookies, it appears to be an authorisation flaw.

You should try some further tests to find out if this is a vulnerability:

  • Try issuing the request without the cookie after the "active session" would have normally timed out.
  • Try creating two sessions and find out if the CSRF token from one session can be used in the other.
  • The creating two sessions under different user accounts and find out if the token from one user can be used in the other. If successful find out which user was associated to the request.
  • Try an invalid CSRF token.
  • Try a missing CSRF token.

Note for creating two sessions you would need a separate browser or you could create one in private/incognito mode.

By "active session" I am referring to a current short-term session on the website (e.g. one with a sliding expiration of 15-30 minutes or so). For sites that implement "remember me" functionality this should be implemented by a different mechanism that creates a new "active session" whenever the user returns, and a new CSRF token to go with it (rather than just creating a long active session).

If any of the above are still successful then you have discovered a session management flaw.

|improve this answer
  • 1
    Noone of the bullets you written works. The concern which I have is - with XSS attack you need to encourage someone to visit your link/website for each attack you want to do. With this kind of issue, you can simply steal CSRF token once, and then do request remotely on behalf of that user. If both session and CSRF token would be verified, then this issue won't exist, as with XSS you can't steal cookie with httponly&secure flags. Does it make any sense? – user67899 Feb 7 '15 at 16:38
  • Then it appears that this is not a security flaw. As the CSRF token is private to that session, it seems it is used as an alternative auth mechanism. – SilverlightFox Feb 7 '15 at 16:40
  • The protection relies on the CSRF token not being stolen - this should not be possible. What is your mechanism for stealing the CSRF token? – SilverlightFox Feb 7 '15 at 16:42
  • If you find an XSS you can steal CSRF token by pulling it out from DOM. Normally with XSS for each attack you need to ask victim to visit your website with exploit. With website veryfing only CSRF token, you just grab the token once and then don't ask victim anymore to visit your link. It makes exploitation much more easier, as less Social Engineering is involved, right? – user67899 Feb 7 '15 at 16:44
  • I follow you now. If you have found an XSS flaw then this is always worse than the CSRF flaw - you can do so much more damage. If you can already inject script into the user's session you can simply add the code to submit the form right there and then (including CSRF token and the auth cookie as the user is already logged in). No need for them to visit the attacker's website as the attacker already has control. – SilverlightFox Feb 7 '15 at 16:47
0

Scenario 1: If the token is generated using a cryptographically secure PRNG, a basic attack like you describe is not possible including if session token isn't sent through that particular request - it don't work as well - so overall this does not work.

Scenario 2: However, if the tokens your application generates are not strong and have bypasses around, this should work but would fail if session tokens doesn't go with it - again as indicated by @AgmLauncher in his answer.

Scenario 3: CSRF token fails + you have the session token, say via XSS - it works.

|improve this answer

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.