Cross-Site Request Forgery aka CSRF is an attack unintentionally triggered by the user himself.
It sends HTTP requests to execute unexpected actions in different ways: trough
img tag to perform
GET requests or with Ajax requests when
POST is required.
You can learn basic CSRF in DVWA.
To perform this CSRF you firstly need to log in, then you must visit a malicious site who will perform a stealth HTTP request who will submit the change password form with specific values.
The original request can be found by using a local proxy like Burp Suite or analyzing HTTP headers with a browser extension like Live HTTP Headers. The payload:
It works like a charm!
height are only used to hide the broken image.
This code displays:
The hash of the password changed in my database from
ab4f63f9ac65152575886860dde480a1, so it worked perfectly…
We can now take a look at the Apache logs.
Access log of the malicious server:
Access log of the DVWA server:
However an error has been generated because we tried to display an image which is not:
In this level a protection has been implemented.
The developper checks the referer to be sure that the incoming request comes from the same local server.
However this control is defective.
If I rename my script on my malicious server from
127.0.0.1.html it will work.
Plus the regexp is mal formed and doesn’t protect special chars like dot ‘
aa127U0B0K1zz.php are also valid filenames.
Finally this level is well protected. The old password is required (which should be only known by the concerned user himself) and cannot be predicted in an automated script.
There is differents ways to secure sensitive actions. A well known method is to use a random token placed in the form and checked after the submission. Another approach is to configure the sessions to close with the browser and with a limited timelife. That way the time window when the vulnerability is effective is shorter.