One Click Is All It Takes: The Danger of
CSRF Attacks

CSRF attack or Cross-site request forgery is a very dangerous and stealthy web security vulnerability that exploits trust from a user's browser for a web application. A successful CSRF attack deceives an authenticated user into performing some operations without his consent-like account modification or payment or financial transaction against his will. Most alarming in such cases is that CSRF attacks usually remain unknown for end-users that make defending against them difficult.

In this blog, we would discuss what CSRF attacks are, how Cross Site Request Forgery works, and other real-life examples of CSRF attacks, as well as best practices to prevent them. Also, this is a valuable guide for developers, security analysts, or even individuals who take an interest in improving their web security edge as it will enlighten on how to defend against CSRF attacks and prevent Cross Site Request Forgery weaknesses in applications.

The XSS intrusions were deemed possible because the attacker exploited trust that a web application has in the browser of its user. In a Cross-Site Request Forgery attack, a hacker issues unauthorized commands from the browser of the user to a web application in which the user is believed to be authenticated. Not being conscious of the fact that it is a malicious request, the browser composes and delivers the request just as it would for the rightful user.

• Authenticated Users: The user logs on to some trusted space, like online banks or e-commerce.
• Malicious Request: The attacker sends an email with a malicious link or embeds a script in the malicious external page.
• Unwanted Action: When the user lands on the malicious external site, the browser automatically sends the request to the authenticated site, which triggers unwanted actions, like transferring money or changing account settings.
• Such Cross-Site Request Forgery is based on a certain type of implicit trust between the application and the browser of the user, thus making it hard to distinguish between legitimate and unwanted requests.

While CSRF attacks are mostly known for financial sites, they do also concern e-commerce platforms. The following is an illustrative example of how a CSRF attack can happen on a shopping site.

Scenario

A customer is logged into the online shopping platform whereby he has added some items in the cart through URLs like add-to-cart? Item=12345&qty=1 without the needed user interaction to do it. If the site has no protection from Cross Site Request Forgery, it is vulnerable to exploitation.

A fake website was created by an attacker, for example example.com.

The attacker embeds a malicious script or hidden image that sends a request to the shopping site's cart endpoint, which includes an expensive item in the user's cart. When a logged-in user visits the attacker's site, the attack executes automatically, and the shopping portal assumes it is from the user. The shopping-cart process validates the cart update, arguing that it must be true since it occurred during the authenticated session of the user.

• Cart Pollution: The user discovers unwanted expensive items in their cart.
• Forced Purchases: If the platform had a one-click checkout, the attacker could have made a purchase on the user's behalf without the user's consent.
• Damage of Brand Reputation: The users might be thinking that the platform has been compromised, thus leading to a loss of confidence.
• Overcapacity of Consumer Support: The customer service team faces challenges due to processing a few refund requests, account cleanups, and complaints by users.

The action of adding items to the cart is done through a GET request, which does not require any further confirmation by the user.

For validating the request's origin there are no CSRF tokens.

Application sends cookies by default without any restrictions on Same Site cookies. The platform does not check Referrer or Origin headers to confirm the legitimacy of the request.

• Further, for protection against CSRF attacks on your web application, you need to put in place multiple layers of security. Here are some practical steps to overcome Cross Site Request Forgery:
• Anti-CSRF tokens are to be implemented: Generate a different and random CSRF token for each user session. Every form/request must include a CSRF token, which will be later verified in a server-side check to determine whether it is a proper request.
• Use Same Site Cookies: Because the cookie has the Same Site attribute defined as Strict browsers will not send the cookie for cross-site requests, hence decreasing the CSRF attack surface.
• Don't use GET for Sensitive Actions: Actions that modify sensitive data should never be GET actions. Examples of actions that fall under this category include changing passwords, making purchases, and updating accounts.
• Validate Referrer and Origin Headers
• Multi-Factor Authentication Implemented: All critical action requires an additional verification step. This ensures that the transaction or account change is blocked even if a CSRF attack is successful.

CSRF attacks are still a concern for modern SPAs, particularly those built with frameworks like React or Angular. Although SPAs mostly use JSON Web Tokens (JWTs) stored in local Storage or session Storage to reduce the risk of Cross Site Request Forgery, they still aren't entirely safe.

Cookies are still subject to CSRF attacks.

• JWTs stored in local Storage cannot be used by CSRF but can be attacked by XSS (Cross Site Scripting).
• Always use CORS headers and CSRF tokens when using cookies for Cross Site Request Forgery protection.

Though often confused with CSRF, clickjacking is an entirely different attack. CSRF exploits the trust a user has towards a particular browser and trusted site to perform unwanted actions on behalf of a user, while clickjacking tricks a user into clicking on something that the user never intended by means of UI manipulation.

In a clickjacking attack, the attacker uses transparent iframes or hidden elements to mislead the user into clicking a link or button which will invoke some actions that are harmful for the said user. Although both attacks are directed towards influencing user behavior, the CSRF primarily hijacks authenticated user sessions while clickjacking aims at deceiving the user to click on something malicious.

Both attack vectors can even be combined, whereby a clickjacking would result in a CSRF attack. To mitigate clickjacking, the implementation of security headers such as X-Frame-Options or a strict Content Security Policy (CSP) is suitable.

Several developers are under a misconception that CSRF attacks are a non-issue for APIs, particularly RESTful or GraphQL APIs. However, this form of attack will provide a score for any API that uses cookie-based authentication.

Some Programming Mistakes Related to CSRF Token Implementation:

While it is crucial in preventing CSRF, there are some common errors that can undermine the use of CSRF tokens:

• Multiple sessions are identified by the same token.
• No server-side validation for the token.
• Using static or predictable tokens.

Some Suggested Recommended Steps that can be taken:

• CSRF tokens might be regenerated for each session or request.
• CSRF tokens should be binded to the user session and should always be validated on the server side.
• CSRF tokens should be random and secure to validate protection.

New paradigms are evolving alongside the traditional validation of CSRF tokens, which presently act as a primary counter against Cross-Site Request Forgery:

• Double Submit Cookie Pattern: The CSRF token is set both in the cookie and in a custom request header, which must match.
• Trusted Types: A feature of CSP that can help prevent XSS-based escalation that may lead to CSRF.
• Nonce-Based Validation: These are action or element-specific tokens, useful in microservices or SPAs.
• Remember that CSRF attacks can happen in OAuth scenarios if the implementation of the state parameter is erroneous or is not validated properly.
• Always generate a random state for an OAuth flow, securely store it, and validate it in the OAuth response to prevent Cross Site Request Forgery.

CSRF attacks are likely to have legal and regulatory implications. GDPR, HIPAA, PCI-DSS, and the whole regulations demand secure treatment of user data. Then, a CSRF attack resulting in carrying out unauthorized actions could lead to violations of these regulations.

CSRF attacks cultivate the trust relationship between a web application and an authenticated user, representing a clear security threat. Without some means of protection, such as CSRF tokens, Same Site cookies, and/or origin validation, an attacker can divert a user's action just by having them click a link or submit a form. Any organization that hopes to protect its web applications must focus on understanding and defending against Cross Site Request Forgery.

By ensuring protection against CSRF, with secure coding practices, and by being aware of newly emerging threats with knowledge, you will protect your users and their information from CSRF plus other malicious attacks.