CSRF Attack Concept, Example with Practical and Prevention

Cross-site request forgery also known as CSRF is OWASP's Top 10 vulnerability most commonly found in web applications.

What is CSRF ( Cross-Site Request Forgery)

This Vulnerability can help the Attacker or Hacker to craft a malicious URL and send it to the victim and able to perform certain actions without the user knowing them.

Concept of CSRF (Cross-Site Request Forgery)

•  Crafted malicious requests can be sent by a different website where the attacker knows that a victim is validated with the site before clicking on malicious javascript code or URL.
• After the victim clicking on malicious requests, it gets routed to the target website where it's routed by a web browser and authentication happens with the target site without a user knowing of it.
• This vulnerability is present in the affected website but not in a web browser or where the attacker hosted malicious requests.

For more simplification, her is two examples will clear your concept of CSRF

Example of CSRF

first, we have one vulnerable web application bankxyz.com which use to transfer funds in different accounts.
Attacker hosting its malicious request in maliciousreq.com and if the victim already logged in to bankxyz.com lands on that website of the attacker.
where attackers using any technique such as automatically executing iframes were just touching mouse curser can execute that malicious request.
the request says to bankxyz.com that send 2000$ to account a number of an attacker and that request automatically gets executed and the transaction gets completed without the user knowing of it.

See how dangerous it can be if exploited.

So this is what the theoretical part is we will see CSRF in practical now.

For understanding how CSRF works we will be using a vulnerable web app of DVWA.

to know how to set it up in an easy way to check out this post.

Install DVWA in Kali Linux using XAMPP.

so let's get started with low security to better understanding.

CSRF (Cross-site Request Forgery) in DVWA (Low)

CSRF (Cross-site Request Forgery) in DVWA (Low)

We have here a password change functionality where users can change passwords.

Let's try to change the password get an idea of how it works.

as an attacker, I used the password change function got a URL GET request which causing the password change which is.

http://localhost/DVWA-master/vulnerabilities/csrf/?password_new=victim&password_conf=victim&Change=Change#

Here I changed the password which is the victim.

Now, as an attacker, I will manipulate this request as I want.
so simply we will change values of password in URL.
I am using Hacker as a new Password.

http://localhost/DVWA-master/vulnerabilities/csrf/?password_new=hacker&password_conf=hacker&Change=Change#

 A victim can still see that request is manipulated so we can encode it to be undetectable. 

This is a URL encoded request...

http://localhost/DVWA-master/vulnerabilities/csrf/?%70%61%73%73%77%6f%72%64%5f%6e%65%77=%68%61%63%6b%65%72&%70%61%73%73%77%6f%72%64%5f%63%6f%6e%66=%68%61%63%6b%65%72&%43%68%61%6e%67%65=%43%68%61%6e%67%65#

 Now we need to deliver this request to the victim in any way possible you can use any hosting website like we stated in the example above or simply using social engineering can also work..
this can be used based on the victim I will teach this another time, for now, we will only focus on CSRF.

The victim will interact with the request and the password will change without even knowing him/her.

 so as you can see password changed to a hacker.

This challenge is quite easy next move on to the Medium challenge.

CSRF (Cross-site Request Forgery) in DVWA ( Medium)

This time we can see the same password change function but if we try using a previous technique.

This time it's showing an error that the request didn't look correct.
we will check with the burp 
the suite that what request is being sent through web-application.


first, we will change the password manually to check what happening there.

As you can see web-application using referer to validate request which means only those can use password change function who are logged in to the web application.
We can easily bypass this referer by adding referer check-in our request, we will be using the same tool, Burp-suite for that.

After using a password change crafted URL we got this request from the burp suite.

where we can see no referer is present there so we will simply copy the referer line from the above request and paste it in there.



 

make sure to edit the password request referer line with a password you want to change and forward the request.

As you can see above password changed this time means we bypassed the security preventing us from changing passwords.

But as you can see this HTTP referer technique Web application is using limited our attack to some extend. we can not send a URL to a victim or host it on the web because we cannot control requests sent by the browser of the victim until we use session hijacking or another attack to manipulate the victim browser combined with CSRF.


Note- ;)

Now you will probably be thinking that it's time for DVWA high level but the problem is I can't explain it over here because this article meant for only CSRF and Solving High and Impossible level of DVWA requires a combination of other hacking techniques as well as exploits some time.

but if you eagerly want to learn that comment down and I will write down an article about a hacking technique you will never going to find on the internet.
Let me know if you want it.

 Now, we know that what CSRF is and how to use this vulnerability to hack victim account and their confidential details.

But, you don't want that victim right ? or a web developer that mistakenly or without knowledge of CSRF left this vulnerability for hackers to take advantage of.

Prevention of CSRF (Cross-site Request Forgery)

For Users

• If you are a user and want to stay away from your account getting hacked or confidential information getting leaked do not click on a suspicious link which can be the doorway to get hacked.
• If you really want to open links and still think about safety so please log out of the web application. yes, CSRF only works if a user is logged in to a web application so don't hesitate to log out because it can save you from getting hacked.
• using good antivirus can also help you with this, Antiviruses now detect online security issues and act as layer safety between you and the website hosted by the hacker.

For Developers

• First of all, get your coding rightly done. because flaws in code cannot be seen while writing it but testing web applications by ethical hackers is must because it's good to get hacked by them instead of black hat hackers. 
• now technical aspect, Use strict user validation techniques like HTTP referer technique to minimize the risk of CSRF but as we have seen above it's not that secure anymore but using it causes some restrictions to the hacker which don't hurt if used.
• Another most common and more secure practice is using the CSRF token which can be used as

1. Validation of CSRF token using request handling.
2. Validation of CSRF token itself.
3. CSRF token tied with user session and session cookies.
4.  never use duplicated CSRF token in cookies.

You may like these posts