“Aren’t you a little short for a Stormtrooper?” In this iconic Star Wars moment, Princess Leia lazily responds to Luke Skywalker, disguised as one of her Stormtrooper captors and using authentication information to open her cell.
In other words, Star Wars acts as an analogy for a cross-site request forgery (CSRF) attack. In a CSRF attack, malicious actors use social engineering so that end-users will give them a way to “hide” in their authenticated session. Disguised as the victim, the attackers can make changes and engage in transactions based on the account’s permissions.
With a cross-site request forgery cheat sheet, you can learn the basic principles underlying these attacks and some best mitigation practices.
What is Cross-Site Request Forgery (CSRF)?
A cross-site request forgery (CSRF) attack involves inheriting the victim’s identity and privileges so that the attacker can perform actions within the site. Typically, browser requests include credential information, like a user’s:
- Session cookie
- IP address
- Windows domain credentials
After a user authenticates into the site, the attackers target functions that allow them to make changes, like:
- Changing an email address
- Creating a new password
- Making a purchase
- Transferring funds
- Elevating privileges
The site treats these forged, authenticated requests as legitimate and authorized. The attacks focus on making changes within the site because any data requested would go to the victim.
CSRF attacks can also be called:
- XSRF
- Sear Surf attacks
- Session Riding
- Cross-Site Reference Forgery
- Hostile Linking
Three Types of CSRF Attacks
Malicious actors can deploy three types of CSRF attacks.
LOGIN CSRF Attack
In a login CSRF attack, malicious actors:
- Get the user to log into an account the threat actor controls
- Victim adds personal data to the account
- Attackers log into the account to collect data and victim activity history
Stored CSRF Flaws
Attackers can store an attack on a vulnerable site using fields that accept HTML using:
- IMG tag
- IFRAME tag
This increases the damage of the attack for two reasons:
- Victims may “trust” the compromised site.
- Victims may already be authenticated into the site.
Client-side CSRF
The client-side CSRF attack manipulates the client-side JavaScript program’s requests or parameters, sending a forged request that tricks the target site. These attacks rely on input validation issues so the server-side has no way to determine whether the request was intentional.
How does a CSRF attack work?
At a high level, attackers do two things:
- Create the malicious code
- Use social engineering to trick the victim
CSRF attacks rely on:
- Web browsers handling session-related information
- Attackers’ knowledge of web application URLs, requests, or functionality
- Application session management only using browser information
- HTML tags that provide immediate HTTP[S] resource access
By clicking on the malicious URL or script, the victim sets up the attacker’s ability to exploit:
- GET requests: Browser submits the unauthorized request.
- POST requests: Victim clicking on a link or submit button executes the action.
- HTTP methods: APIs using PUT or DELETE could have requests embedded into an exploit page, but same-origin policy restrictions in browsers can protect against these unless the website explicitly allows these requests.
How is Cross-Site Request Forgery Different from Cross-Site Scripting (XSS)?
These attacks exploit different aspects of web interactions:
- Cross-Site Request Forgery: leverages use identity to take state-changing actions without victim consent
- Cross-site scripting: inject malicious code into web pages to manipulate user input and access sensitive data
Best Practices for Mitigating CSRF Attack Risk
A successful CSRF attack exploits specific application vulnerabilities and a user’s privileges. Following some best practices, you can mitigate these risks.
Use Synchronizer Token Patterns
As the most effective mitigation, many frameworks include CSRF protection by default so you may not have to build one yourself. The server-side-generated CSRF tokens should be:
- Unique per user per session
- Secret
- Unpredictable
The server-side component verifies the token’s existence and validity, comparing it to the token in the user session and the site should reject the request without it.
The mitigation uses per-session tokens because they offer the end-user a better experience. A per-request token would be more secure by limiting the available time frame for using them. However, for every user interaction, the site would need to generate a new token.
Alternative: Signed Double-Submit Cookie Patterns
In cases where you can’t use the synchronizer token, you could substitute the easy-to-implement, stateless Double-Submit Cookie pattern. With the Signed Double-Submit Cookie, you have a secret key that only the server knows to mitigate injection risks that would compromise the victim’s session.
While the Naive Double-Submit Cookie methods may be easier to implement and scale, attackers can bypass the protection more easily through:
- Subdomain exploitation
- Man-in-the-middle (MitM) attacks
Disallow Simple Requests
Simple requests are cross-origin HTTP requests that can be sent directly from the browser to the target service without getting prior approval. If the site uses <form> tags that allow users to submit data, the application should include additional protections. Some examples of additional protections include:
- Ensuring servers or APIs do not accept text/plain content types
- Implementing custom request headers for AJAX/APIs to prevent usability issues that using a double-submit cookie would create
Implement Client-side CSRF Mitigations
Since client-side CSRF attacks bypass traditional mitigations, you should implement the following:
- Independent requests: Ensure attacker controllable inputs cannot generate asynchronous requests
- Input validation: Ensure that input formats and request parameter values only work for non-state-changing operations
- Predefined Request Data: Store safe request data in the JavaScript code
SameSite (Cookie Attribute)
The browser uses this attribute to determine whether to send cookies with cross-site requests and has three potential values:
- Strict: prevents the browser from sending the cookie to the target site in all cross-site browsing contexts that involve following a regular link
- Lax: maintains a logged-in session when the user follows an external link, but blocks high-risk request methods
Verify Origin with Standard Headers
This method examines the HTTP request header value for:
- Source origin: where it comes from
- Target origin: where it’s going to
When these match, the site accepts the request as legitimate. If they do not match, it discards the request.
Involve the User
Involving users means they have to take action that mitigates risks from unauthorized operations. Some examples include using:
- Re-authentication mechanisms
- One-time tokens
While CAPTCHA requires user interaction, it does not always differentiate user sessions. While it would make attacker success more difficult, it isn’t a suggested mitigation technique.
Graylog Security: Mitigating CSRF Risk with High Fidelity Alerts
Graylog Security provides prebuilt content that maps security events to MITRE ATT&CK so organizations can enhance their security posture. By combining Sigma rules and MITRE ATT&CK, you can create high-fidelity alerting rules that enable robust threat detection, lightning-fast investigations, and streamlined threat hunting. For example, with Graylog’s security analytics, you can monitor user activity for anomalous behavior indicating a potential security incident. By mapping this activity to the MITRE ATT&CK Framework, you can detect and investigate adversary attempts at using Valid Accounts to gain Initial Access, mitigating risk by isolating compromised accounts earlier in the attack path and reducing impact.
Graylog’s risk scoring capabilities enable you to streamline your threat detection and incident response (TDIR) by aggregating and correlating the severity of the log message and event definitions with the associated asset, reducing alert fatigue and allowing security teams to focus on high-value, high-risk issues.
