Cross site request forgery (CSRF) Attack One of the Web Trending Vulnerability.
Hi guys!! Today we will talk about one of the trending vulnerability cross site request forgery attack.
Below I have divided this topic in number of parts to get better perceptive.
Agenda:-
- Introduction
- Consequences
- Exploitation
- Mitigation
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://bank.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://bank.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://bank.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.
III. Secret Token: Server shared the secret token between source and destination, Included in hidden form field.
ليست هناك تعليقات:
إرسال تعليق