OWASP TOP 10: CSRF (Cross Site Request Forgery)
Today, we will be covering Cross-site Request Forgery. Our goal for today is
- Learn the methodology behind Cross-site Request Forgery
- How to carry out Cross-site Request Forgery?
- How to know if the attack was successful?
- How to detect a Cross-site Request Forgery using Snort?
Methodology
Cross-site Request Forgery is an attack that forces an end user to execute unwanted actions on a web application where they’re currently authenticated.
How to carry out the attack:
Here we have a prompt that is used to change a user password. Let’s pretend this was like a website for a famous bank ie, Bank of America.
What we can do is change the current user password to what we want the password to be by simply sending a link
Here we are verifying that the admin account password is the password.
Let’s get the request(link) that changes the user password.
Once we press the change button, we get the following link:
|
|
As you can see in the URL, it shows us what password we change it to. We can replace it with any password. Let’s change the password to WOW123 by just using the link.
|
|
Let’s verify the credentials by using the Test Credentials.
Now that we know what we can achieve with cross-site request forgery Let’s make the link less obvious. We can use shorten our link.
|
|
I will be using this website: https://shortify[.]pro/
This is my new link:
https://jx[.]ax/Jk
Let’s pretend I’m a customer at bank of America, and I clicked a link within an email: Let’s see what happens.
Alright, let’s try the original password to see if it works.
Let’s try the new password (gotyourpassword)
Boom. We successfully changed the user password to what we wanted. Let’s revert these changes to the original password.
But first, let’s capture this attack with pfsense packet capture, so we can see what the attack would look like in a PCAP.
Once that start rolling, we will execute the link to change our current password to the original password
|
|
Stop our packet capture
Now, let’s check our credentials
looks like the password is set to the original password.
How to know if the attack was successful?
For this, we will download our packet capture from pfsense
Then, the packet capture will be downloaded to the PC.
Here is the packet capture for the people who can’t get it:
As we can see, the client initiates a GET request with: http://172.20.25.16/DVWA/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#
Then, the server responds with 200 OKs, and the content length is 1989
Let’s see what a failed CSRF attack looks like using the impossible difficulty
As we can see, using the Content-Length wouldn’t help us. But, there are some other things we can look at:
- Source IP, Is it coming from our IP range or an unknown source?
- For the impossible, does the password_current request match the one with the one we have in the database? If not, then it raises a question.
- What time did the password request was made? Was it out of operating hours?
Detecting Cross-Site Request Forgery
We will write a snort rule that detects when a request to the password page is made.
|
|
This is the rule:
|
|
Let’s explain what we have here.
Alert me when any TCP connections are going to 172.20.25.16:80 (port 80 is the web server)
- The incoming TCP connection has a “GET,” and the URI that is getting has a component of: ?password_new
Now run the snort in IDS mode
|
|
Now, let’s change back the password to password.
Well, that is all I have for Cross-site request forgery. See you guys at the next one.