This lab's email change functionality is vulnerable to CSRF. It attempts to block cross domain requests but has an insecure fallback.
To solve the lab, use your exploit server to host an HTML page that uses a to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
After accessing the lab i intercepted the change email request and sent it to repeater for further analysis:
What i noticed if i do even a small change in the referer header i get "Invalid referer header"
error but what i found interesting is when i delete the header completely the request does get through so i need take this in mind when building my CSRF poc. I started crafting my CSRF poc and it look like this:
a simple html page hosted on my exploit server that have a form which will be auto submitted when visiting the exploit page but when the POST request fo the form will be sent will not have a referer header and that's due the meta tag added at the first of the html page:
so if i simply copy and paste this CSRf poc into my exploit server page and click Store
and deliver exploit to victim
i can see that the lab is solved which confirms that the victim's email is changed.