Writeup: CSRF where Referer validation depends on header being present @ PortSwigger Academy
This is a writeup for the Lab “CSRF where Referer validation depends on header being present” from PortSwiggers Web Security Academy:
Learning path: Client-side topics → Cross-site request Forgery (CSRF)
Lab: CSRF where Referer validation depends on header being present | Web Security Academy
Practise exploiting vulnerabilities on realistic targets. Record your progression from Apprentice to Expert. See where…
Python script: script.py
- Lab application contains a email change feature vulnerable to CSRF
- CSRF protection uses Referer header
- Known good credentials
- Create some HTML to change a viewers email address
Find weak CSRF protection
As usual, the lab application is the blog website. The vast majority of considerations are the same as in the Lab: CSRF where token validation depends on request method so I will not duplicate it in here, please refer to that document.
I login with the known credentials for
wiener and change the email address. This results in the following request:
There is no CSRF-token or any obvious protection visible, sending the request to Repeater and change the email again works without issues.
The first attempt is to use a trivial attack like in the Lab: CSRF vulnerability with no defenses:
The lab name contains the spoiler alert already: It does not work here
Fortunately, the error message gives a clear indication about what might be wrong.
The referer header is usually added by the browser automatically when a link is followed. In this case, the referer for my malicious form is my exploit server. So the next step is to put this request into Repeater and simply remove the header, and:
The request goes through and the email gets changed. So the only protection that is in place here is the content of the referer. Relying on a client provided value is always a bad thing. A malicious actor that is able to intercept the traffic can manipulate it at will.
While I can modify my own traffic, I do not have the capability for the traffic of my victim. In this case I need to coerce the browser of the victim to not send the header.
Fortunately, the documentation at mozilla.org shoes the answer:
So I update my exploit page with the relevant header:
This time after viewing the exploit my email address got changed.
As an alternative, the directive can also be integrated into the HTML code itself:
All that is left now is to press
Deliver exploit to victim in order to
Bottom line of this lab is to never trust any client provided data in security decisions.
Originally published at https://github.com.