Should CSRF bypassHeaders ignore the presence of a CSRF token in the cookie ? #12457
Replies: 1 comment
-
Yes that's exactly how it works. Here is the implementation: The important bit here is
I don't fully understand... So you say if a the cookie contains the CSRF token then we should check for a csrf header... ok but what if there is no csrf header or they do not match? So if the check is negative then look for the
CSRF protection is primarily designed to prevent attacks that exploit the trust a web application has in the browser of a logged-in user. The risk it addresses is specific to scenarios where an attacker can trick a browser into making unauthorized requests to a web application with which the user is authenticated, leveraging the user's credentials, cookies, or sessions. As how I understand it, for non-browser clients, such as mobile apps, desktop applications, or server-to-server communication, CSRF protection is generally not as relevant or necessary. These types of clients do not inherently perform automatic session management or cookie handling in the same way browsers do. For instance, they typically use token-based authentication (like OAuth or API keys) carried in the header of each request, which doesn't rely on cookies and thus isn't susceptible to CSRF attacks. Given this context, your original approach to using the In situations where both browser-based clients and non-browser clients interact with your API, it's essential to implement security measures that accommodate the distinct nature of each client type without compromising overall security (e.g. using token-based authentication for non-browser clients, clearly separating them from browser-based session management). Also I did not fully understand: The non-ui client you are talking about, do you have full control over it? And you say some 3party is adding cookies to it - like can you check which headers the 3party adds to the request before it get's fired to your Play application? This way you might can already control, maybe with a kind of white-/blacklist which headers the 3party is allowed to add or check if the 3party is adding a Play session cookie to the request and could deny such a request on the non-ui client side already before it gets fired to you application. Just some idea's, based on my undertanding of how CSRF works. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone,
I have a backend application exposing an API used by a frontend which uses a login password header authentication and can retrieve a PLAY_SESSION.
Using the PLAY_SESSION cookie requires the use of a CSRF-TOKEN.
The CSRF-Token mechanism works well and is implemented on the frontend without any problems.
The problem came from the usage of the api directly with a non-ui client. This client uses the same authentication system with the header authentication. But a third party adds cookies to the client http request and i have no control on this process resulting in the activation of the CSRF validation on the Play side.
In the documentation, the play.filters.csrf.header.bypassHeaders seems to be a good candidate to help us avoid the csrf token validation and i started with the following configuration:
Everything good the client no longer gets the unauthorized page from the play server.
And here is where it gets weird for me, now the presence of a CSRF token in the cookie is ignored if the Csrf-Token header equals "nocheck".
I would expect the header to be checked if the cookies contains a CSRF token regardless of the header value and otherwise skip the validation if the header value equals "nocheck"
Seem like a CSRF attack can use any header known in the bypass list to have Play ignoring the CSRF token validation.
Did i misunderstand a concept ? or a configuration ?
Beta Was this translation helpful? Give feedback.
All reactions