Cross Site Request Forgery ('CSRF')

ID

java.cross_site_request_forgery

Severity

high

Resource

Authentication

Language

Java

Tags

CWE:352, NIST.SP.800-53, OWASP:2013:A8, PCI-DSS:6.5.1

Description

Cross-Site Request Forgery (CSRF) is a security vulnerability that occurs when a malicious actor tricks a user’s browser into performing unwanted actions on a trusted web application where the user is authenticated. It primarily exploits the trust that a web application has in an authenticated user’s browser.

It can lead to unauthorized actions being executed in a web application on behalf of the user, potentially compromising personal data, making unauthorized transactions, or performing administrative operations.

Rationale

CSRF exploits the trust that a web application has in the user’s browser. Essentially, the attacker crafts a request that the user’s browser sends to a web server where the user is authenticated.

The key vulnerability is the application’s inability to verify that the request originated from its own legitimate web pages and intentionally made by the user, rather than from a malicious site. This is why CSRF protections typically involve adding unique tokens to forms that the server can verify came from its own pages.

If the vulnerable application does not have the necessary protection, the attacker can execute arbitrary actions on the user’s behalf.

Example in Java Web Application

A common scenario is when a user is logged into their bank account. Suppose there is a vulnerable endpoint /transferMoney that processes transactions without verifying the origin of the request. The attacker might send an email with a malicious link to the logged-in user, which their browser executes automatically:

GET http://bank.example.com/transferMoney?amount=1000&toAccount=attackerAccount

If the bank’s application does not verify the legitimacy of the request, it might execute the transaction as if the legitimate user initiated it themselves.

Java web applications often deal with CSRF vulnerabilities through a lack of token validation within forms and requests. Java web frameworks like Spring MVC, for example, provide built-in support for CSRF protection, which when not implemented, can leave applications vulnerable.

Remediation

The most common protection strategy against CSRF is to use anti-CSRF tokens, to ensure that requests are originated from the legitimate user. The token should be generated on the server backend, and included in every form or request to the backend.

Additional protection techniques that do not seclude the need for anti-CSRF token:

  • Validate Referer Header: In some cases, checking the Referer or Origin headers can provide another layer of protection, ensuring that the request originates from the same site.

  • Force User Interaction: Force significant actions to require additional confirmation steps, like re-authentication or other forms of verification.

  • SameSite Cookie Attribute: Use the SameSite attribute for cookies to prevent them from being sent in cross-site requests.

Implementing these strategies in your applications will significantly reduce the risk of CSRF attacks.

Java Example Using Spring Security:

If you’re using Spring Security, CSRF protection is enabled by default in recent versions. You must ensure that each request carries a valid CSRF token:

  • Add CSRF token in your form

<form action="/transferMoney" method="post">
  <input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>
  Amount: <input type="text" name="amount"/>
  To Account: <input type="text" name="toAccount"/>
  <input type="submit" value="Transfer"/>
</form>

  • Configure Spring Security: If not already, make sure CSRF protection is enabled in your security configuration.

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
          .csrf().and()
          .authorizeRequests()
          .antMatchers("/public/**").permitAll()
          .anyRequest().authenticated();
    }
}

References