Cross Site Request Forgery (CSRF) Attack is One of the biggest Website Vulnerability.
CSRF attack is the trending vulnerability for web application. Below i have divided this topic in number of parts to get better perceptive.
You need to learn as follow-
- Introduction
- Consequences
- Exploitation
- Mitigation
- CSRF Prevention
1. Introduction:
What is cross site request forgery attack?
Cross site request forgery is also known as XSRF, “Sea Surf”, and Session Riding.
Cross site request forgery is a attack which comes under top 10 of OWASP (i.e Open Web Application Security Project) vulnerability and it is a common possible exploited vulnerability type.
Approximately 24% of the web application is vulnerable to this attack.
It is an attack that forces the end user to execute unwanted action on a web application in which they are currently authenticated. Cross site request forgery attack doesn’t theft the data, since he has no way to see the response of forged request.
Cross site request forgery attack uses the trust of the end user in the application and forces the user to perform certain action unknowingly of the attacker choosing, and compromise many confidential details.
Before moving forward to the exploitation, we should know the consequences of this attack.
2. Consequences
Cross site request forgery is an attack which is performed based on the user action in the web application. So depending on the action being taken by user it leads to serious consequences like an embarrassing social media post, losing money from your online account and many more.
It is also possible to store CSRF (i.e. cross site request forgery attack) in the vulnerable site itself.
3. Exploitation
Let’s now have look in to exploitation technique of force Based cross site request forgery attack.
This attack will compromise the following steps:
I. Attacker need to create exploit URL or script.
II. Tricking victim to execute that malicious URL.
In order to forge a HTTP request, an attacker typically profiles the target site first that should be similar to legitimate site as much as possible. This can be done either by reviewing the HTML source or by inspecting the traffic from burp suite or any other proxy tool.
Example:
Suppose John want to transfer some amount to Bob, and application was designed to use a GET Request:
GET http://xyzbank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Maria now decides to exploit this web application vulnerability using John as her victim. Maria first constructs the following exploit URL which will transfer $100,000 from John account to her account. She takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:
http://xyzbank.com/transfer.do?acct=MARIA&amount=100000
After that, she will create the exploit URL and sends to a Victim.
Exploit URL
<a href="http://xyzbank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
Through social engineering, she tricks the victim and once the victim clicked the exploit URL. The browser will submit the request to bank.com without any visual indication that the transfer has taken place.
4. Mitigation-
There is one misconception, that the attack can be prevented by using the post method. Since the attacker cannot construct a malicious link, a CSRF attack cannot be taken place. Unfortunately, this logic is incorrect.
There are several method in which attacker tricks the victim in to submitting forged POST request.
Number of ways by which we can defend our application from CSRF attack are mentioned below:
I. Header validation:
- Try to use the referrer header in your application.
- Try to use header of your own i.e. Custom header, And Must always use JavaScript XMLHttp Request then HTML forms.
II. Relies on the browser’s same origin policy.
III. Secret Token: Server shared the secret token between source and destination, Included in hidden form field.
Forging login requests
An attacker may forge a request to log the victim into a target website using the attacker’s credentials; this is known as login CSRF. Login CSRF makes various novel attacks possible, for instance, an attacker can later log into the site with his legitimate credentials and view private information like activity history that has been saved in the account. This attack has been demonstrated against Google and Yahoo.
How to Prevent CSRF Attacks?
CSRF prevention techniques work by embedding additional authentication data into requests that allows the web application to detect requests from unauthorized locations.
Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as “form keys”. Many frameworks (e.g., Drupal.org 4.7.4+) either have or are starting to include this type of protection “built-in” to every form so the programmer does not need to code this protection manually.
Add a hash (session id, function name, server-side secret) to all forms.
Checking the referrer header in the client’s HTTP request can prevent CSRF attacks. Ensuring that the HTTP request has come from the original site means that attacks from other sites will not function. It is very common to see referrer header checks used on embedded network hardware due to memory limitations.
“Although CSRF is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser’s cookies at the end of each browser session.
- Check if your framework has built-in CSRF protection and use it
If framework does not have built-in CSRF protection add CSRF tokens to all state changing requests (requests that cause actions on the site) and validate them on backend. - For stateful software use the synchronizer token pattern
- For stateless software use double submit cookies
- Implement at least one mitigation from Defense in Depth Mitigations section
– Consider SameSite Cookie Attribute for session cookies but be careful to NOT set a cookie specifically for a domain as that would introduce a security vulnerability that all subdomains of that domain share the cookie. This is particularly an issue when a subdomain has a CNAME to domains not in your control.
– Consider implementing user interaction based protection for highly sensitive operations
– Consider the use of custom request headers.
– Consider verifying the origin with standard headers. - Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques.
- Do not use GET requests for state changing operations.
– If for any reason you do it, protect those resources against CSRF
Source – Wikipedia, Owasp
