CSRF Testing
Notes from HackTheBox Academy
If any CSRF token exist to prevent CSRF attack, check if it can be bypassed.
CSRF Bypass And Security Check
Remove the CSRF
Remove the CSRF token from the request or only keep the header. Sometime, the validation may only check for the header being present.
Arbitrary CSRF token value
Change the CSRF value for an arbitrary value of the same length and pattern.
Check if the CSRF token is tied to the user session
In two different browser sessions, copy the CSRF token for a request for one account (make sure not to send the request to the server) and paste it in the same request, but using the session of another account. In a proper implementation, the CSRF token should be tied to the user session.
Change the method from POST to GET
Example:
Session Fixation + CSRF
Sometime, the server only validates that the CSRF token in the Cookie header and the value placed in the request body are equal. In these cases, the CSRF token value is not stored server-side and compared to the one sent by the client making the request. If a session fixation exist, it might be possible to set an arbitrary CSRF token value both in the Cookie and in the request body. The server would then consider the request valid since both CSRF value are equal.
Anti-CSRF Protection via the Referrer Header
The Referrer header indicates who requested the resource. This header can be used as an anti-CSRF protection, but is an incomplete ways of protecting against CSRF. A tester can try to send the request without the Referrer header.
This piece of code can be added to the attacker CSRF script.
An improper validation of the Referrer header might lead to some bypass. For example, a tester might try to prepend and append elements to the URL to trick the server validation.
Weak CSRF Token
Check if the CSRF Tokens are forged from an unsecure algorithm such as md5(username)
, sha1(username + current date)
, etc. In a secure anti-CSRF protection mechanism, the CSRF token is unpredictable.
Last updated