Preventing CSRF Attacks on Your Website.

Introduction

What is a CSRF attack?

Cross-site request forgery(CSRF) is a web security vulnerability that occurs when a malicious website, email, or blog causes a user’s web browser to perform an unintended action on a trusted site for which the user is currently authenticated. In order to do this, the attacker tricks the victim into sending a malicious request to a site the user is already authenticated to. The request is made using the victim’s own browser, so the web application has no way to distinguish it from a legitimate request. As a result, the attacker can perform actions on the web application on behalf of the victim. These malicious requests can help change a user’s password, share confidential information, and even transfer funds on behalf of the user to the attacker’s account. A perfect scenario of a CSRF attack could be an attacker tricking a victim into making a request to a web application to transfer money from the victim’s account to the attacker’s account, the web application will process the request because it appears to be a legitimate request from the victim. The victim is unaware that the request was made and may not even realize that their account has been compromised until it is too late.

A perfect illustration of how it is carried out is the example below:

How does CSRF attack work?

A CSRF attack works by exploiting the trust that a web application has in a user’s browser. When a user authenticates with a web application and their browser stores the authentication cookie, the web application trusts the user’s browser to make requests on behalf of the user. A cookie is a small piece of data that is stored on a user’s computer by a website in the browser. It is used to identify the user and to store information such as authentication cookies that are related to session cookies and also about the user’s preferences or actions.

An attacker can leverage this trust to perform actions on the web application by tricking the victim’s browser into making a request to the website with the victim’s own authentication cookie. The website has no way to distinguish a malicious request from a legitimate request and will process it as if it were a request made by the victim.

They are several ways an attacker can trick a victim into making a request to a web application:

• The attacker can send a malicious link to the victim through mail or instant message. When the victim clicks on the link, their browser will make a request to the web application with their authentication cookie, allowing the attacker to perform actions on the web application on behalf of the victim.
• The attacker can embed a malicious link on a web page or blog that makes a request to the web application when the page is loaded. If the victim views the page, their browser will make the request to the web application with their authentication cookie. For example, a blog post links you to another section of the page let’s say “Sports” the user would have no idea that the link is embedded with a malicious link that does the following:

<a href="<https://chimebank.com/transfer?acct=0043582983637&amount=$2000>">Sports</a>

So, when the clicks on the tag “Sports”, an authenticated HTTP request is sent to chime bank that transfers $2000 from the user’s account to the attacker’s account without the user even knowing!

• Another way an attacker can trick their victim into a CSRF attack is by tricking a user into a malicious site through social engineering. For example, sending a phishing email asking the victim to urgently visit this URL to restore access to their bank account. Thus, when the user visits the malicious site,https://malicioussite.com/restoreaccountthe form submission is automatically initiated. The vulnerable website https://www.chimebank.com accepts the request and changes the email address to attackemail@gmail.com , believing that the victim had intentionally submitted the form (due to the presence of the session cookie). The attacker can then utilize the password reset feature to send a password reset email to this new address. Using this method, the attacker is able to take control of Alice's account by resetting her password and locking her out.

How to prevent CSRF attacks

CSRF attacks can be a big threat to users and even websites. Below is a list of methods you can use to prevent a CSRF.

• Using synchronizers token
• Using same-site cookies
• Implementing a content security policy

Using Synchronizers Token

In this method, the website generates a unique, secret token and assigns it to the user’s session. The token is then included as a hidden field in forms that are displayed to the user or as a URL parameter in links that the user can follow. When the user submits the form or follows the link, the token is sent back to the website along with the request. The website can then verify the token to ensure that the request is legitimate. If the token is missing or does not match the expected value, the web application can reject the request as a potential CSRF attack. Using synchronizer tokens is an effective way to prevent CSRF attacks because it ensures that the website can distinguish between legitimate requests and malicious requests. However, it is important to ensure that the tokens are properly implemented and securely stored to prevent an attacker from being able to obtain or guess the tokens.

Using Same-Site Cookies

Same-site flag instructs the web browsers to send cookies differently depending on how the user interacts with the site that set out the cookie. Same-site cookies are a relatively new feature of web browsers and are designed to mitigate the risk of CSRF attacks by ensuring that a cookie is only sent with a request if the request originates from the same site that set the cookie. This helps to prevent an attacker from being able to craft a malicious request that includes a victim’s cookie and send it to a web application from a different site.

To use same-site cookies, a web application must set the SameSiteattribute of the Set-Cookie header when sending a cookie to the browser. The attribute can be set to either Lax, Strict, or None .

• Lax mode allows the cookie to be sent with top-level navigation, such as when the user clicks on a link or types a URL into the address bar.
• Strict mode only allows the cookie to be sent with requests that originate from the same site.
• None This cookie is meant for embedded content.

Implementing a content security policy

A content security policy(CSP) is a browser security standard that controls what domains, subdomains, and types of resources a browser can load on a given website. By specifying a CSP, the web application can prevent the browser from loading malicious content, such as scripts or stylesheets, from untrusted sources. This can help to protect against XSS and CSRF attacks, as well as other types of attacks that involve the injection of malicious content into a webpage. To implement a CSP, the website must specify a **Content-Security-Policy**header in the HTTP response. The header contains a set of directives that define the sources of content that are allowed to be loaded on the webpage. For example, the following CSP header allows the web application to load scripts and stylesheets only from the same site as the webpage:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self';

Implementing a CSP is an effective way to prevent XSS and CSRF attacks and is supported by most modern web browsers. However, it is important to carefully configure the CSP to ensure that it does not block legitimate content from being loaded on the webpage.

Conclusion

In conclusion, it is essential for web developers to understand the threat of CSRF attacks and take steps to protect their applications and users. By understanding how CSRF attacks work and the methods that attackers use to exploit trust relationships between websites and users, developers can implement effective countermeasures such as synchronizer tokens, same-site cookies, and content security policies. By following best practices and staying up-to-date on the latest security threats, developers can help to ensure the security and integrity of their web applications and protect their users from harm! Enjoy reading cheers!!