Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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).
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:
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.
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.
