chethan (Community Member) asked a question.
We have a CWE-352 vulnerability for one of our application codebases and looking for suggestions to resolve it.
Current State: In our Spring boot application, we have enabled web security and in the overridden configure() method we currently are disabling the csrf feature as shown below. We use the Basic Auth feature to authenticate the requests, today.
//Code
protected void configure(HttpSecurity httpSecurity) throws Exception {
httpSecurity.csrf().disable().authorizeRequests().anyRequest().authenticated().and().httpBasic();
}
This is a REST API application and we don't have a web front end.
Issue: Enabling the csrf feature is causing the API requests to fail with a 403 Forbidden Status
Let me know if you have any suggestions that might help. Thanks!
.png){kind=logo}
Hi @chethan (Community Member),
CSRF attack vectors also apply to Basic Auth. The reason you would receive the 403 Forbidden status is that everything is working as intended. CRSF protection is in place which generates a secret on the server-side. This secret is sent to the client and the client is expected to send the secret back to the server for the request to work (if the client omits the secret, it receives a 403 Forbidden). This remediates CSRF as any cross-site requests would receive the Forbidden status as an attacker would not know the secret, and if it is generated securely an attacker would also not be able to guess it.
I would generally recommend against Basic Auth as it sends credentials in plaintext with every request (base64 encoding doesn't provide any security and can easily be decoded again). If you must, please make sure that you have TLS in place. Please explore moving to a more sophisticated authentication mechanism that generates some token and sends back-and-forth the token as opposed to the actual passwords.
If the new authentication mechanism stores the token in a cookie, please make sure to enable the built-in CSRF protection and implement sending back the CSRF secret to the server in the client. Also, please make sure to set the `HttpOnly` (makes sure that JavaScript cannot access the cookie, i.e. is a solid defense mechanism again Session Hijacking attacks) and `Secure` (tells the web browser that this cookie must not be sent over insecure channels) cookie flags.
If the new authentication mechanism stores the token in LocalStorage, CSRF attack vectors do not apply and you may want to disable the built-in CSRF protection and propose a mitigation. However, please keep in mind that storing secrets in LocalStorage (as opposed to cookies) increases your attack surface for Cross-Site Scripting as token protection mechanisms like `HttpOnly` could not be applied.
Thank you,
Florian Walter