CSRF BYPASS
these are additional csrf protection bypasses that may prove helpful during engagements or bug bounty hunting.
NULL VALUE
making the CSRF token a null value may sometimes work because the check may only be looking for the header and may not necessarily validate the token value. as long as the header is provided in the request, the null csrf token may be able to bypass restrictions or protections.
RANDOM CSRF TOKEN
Setting the CSRF token value to the same length as the original CSRF token but with a different/random value may also bypass some anti-CSRF protection that validates if the token has a value or equal to the length of the orignal
USING ANOTHER SESSION'S CSRF TOKEN
using the same CSRF token across accounts may work in applications that do not validate if the CSRF token is tied to a specific account or not and only check if the token is algorithmically correct
REQUEST METHOD TAMPERING
this anti-CSRF protections bypass requires changing the request method from POST to GET and vice versa
DELETE THE CSRF TOKEN PARAMETER OR SEND A BLANK TOKEN
not sending a token works fairly often because common application logic mistakes. Applications sometimes only check the token's validity if the token exists or if the token parameter is not blank.
SESSION FIXATION TO CSRF
another defense against csrf is double-submit cookie. this mean that the sent request will contain the same random token both as a cookie and as a request parameter, and the server checks if the two values are equal. If the values are equal, the request is considered legitimate. webapps with this type of defense mechanism probably isn't keeping the valid token on the server-side. the webapp won't have a way of knowing if any token it receives is legitimate and merely checks that the token in the cookie and the token in the request body are the same. If this is the case and a session fixation vulnerability exists, an attacker could perform a successful CSRF attack.
ANTI-CSRF PROTECTION VIA THE REFERRER HEADER
If an application is using the referrer header as an anti-CSRF mechanism, adversaries can try removing the referrer header.
BYPASS THE REGEX
this protection method is implemented by sites where the Referrer has a whitelist regex or a regex that allows one specific domain. suppose that the Referrer Header is checking for google.com. adversaries could try something like www.google.com.pwned.m3, which may bypass the regex! If it uses its own domain (target.com) as a whitelist, try using the target domain as follows www.target.com.pwned.m3
Last updated