If I read this correctly the way Tomcat protects against CSRF leaves it vulnerable to the situation where the CSRF token is duplicated in the cookie and request parameters which allows the attacker to simply invent a token (as detailed here under CSRF token is simply duplicated in a cookie). Am I right or missing something stupid?
1
-
How can evil.com set a cookie for legit.com?– user163495Commented Feb 25, 2020 at 9:37
Add a comment
|
1 Answer
You are correct, but this requires a specific and rather unusual behavior of the protected web application to work.
You are referring to the chapter "CSRF token is simply duplicated in a cookie" from the portswigger guide. Let me quote the essential part and highlight the crucial "if":
In this situation, the attacker can again perform a CSRF attack if the web site contains any cookie setting functionality. Here, the attacker doesn't need to obtain a valid token of their own. They simply invent a token (perhaps in the required format, if that is being checked), leverage the cookie-setting behavior to place their cookie into the victim's browser, and feed their token to the victim in their CSRF attack.
Having a functionality that allows an attacker to set the cookie of another user is very uncommon and the actual use cases for such a functionality are limited. Yes, you can craft an artificial scenario, where this CSRF protection can be circumvented, but you will not find this in many applications in the wild.
Beside this important caveat, your analysis is correct.
