Have you ever heard about Blind XSS?. What is it about?. Where does it happen?. After looking for vulnerabilities in a subdomain for some days and failed, it is normal to give up and take a new domain from the subdomains recon list. But you forgot that the application usted by the contact to read inquiries could be vulnerable to XSS. And, with this in mind, there is only one way to find it out: a Blind XSS.
BLIND XSS
Blind XSS is one more kind of XSS. It is categorized as Blind beacuse once we send the payload, it gets executed in the browser due to the application where contact staff review all requests from customers, is not validating data, but we cannot verify the execution. The data we sent with the contact form (where it is our payload) maybe is saved by the web server and, as there is no input and output data validation, payload gets loaded as it is and gets interpreted and executed by browser.
Next, we made a graphic to show the flow from the contact form until we get the evidence in XSSHunter service:
- We fill up the contact form, inserting the XSS payload in every field we can and send the form.
- The contact staff open the request received and, due to an absence of data validation, browser interprets and executes the XSS payload.
- The XSS payload makes a request to our custom domain, loading a javascript file which collects information from victim and takes some screenshots. All this data is sent to XSSHunter service and inserted in our profile, which is related to the custom subdomain.
- Logging into XSSHunter, we can access all information collected and all screenshots taken.
WAIT, WHAT IS XSSHUNTER?
XSSHunter is a known platform which allows you to find Blind XSS vulnerabilities by receiving all the data and screenshots collected from the execution of a javascript file in victim’s browser. Although this article is based on XSSHunter, there are articles about to build your own XSS Hunter service in a VPS. I mention this because there are Bug Bounty programs that are worried about sending potentially sensitive information to a third party.
HOW IT WORKS?
First of all, when creating a new account, some data is requested in special the name for custom subdomain. This subdomain will be related to our profile and will be invoked once the payload is executed, collecting all the information and sending it to XSSHunter:
Once the account was created and logged into the XSSHunter application, we found three tabs:
- XSS Fires: where we can see all XSS fired.
- Collected pages: where we can see all the screenshots taken.
- Payloads where we can see a list of payloads for different situations.
This three options are shown in the following image:
In XSS Fires tab is shown all the entrances for any XSS payload executed. There are three fields: Thumbnail which shows a preview about the screenshot, Victim IP which details the victim’s IP address and Vulnerable Page URI which details the URL address that executed the payload:
In Payloads tab, a list of different payloads is displayed that we can use depending on the situation we find ourselves in:
Finding a blind XSS
For any subdomain on which we are looking for vulnerabilities, it is important to give a try to the contact/support form, inserting a payload in all the fields allowed because we don’t know what param are not being validated. In example, the contact form i filled up was the following:
When the contact staff opened the inquiry received, the payload was executed and a request to our custom subdomain was made, loading the javascript file which advice him about what was happening. This javascript, as said previously, will collect the information and screenshots and will send them to our custom subdomain in XSSHunter:
Everytime the payload was executed, we received an email for advice us about on which domain it was executed:
Logging into the XSSHunter application and moving to XSS Fires tab, we observed an entrance about some data collected from victim:
Also, at right of the menu, there were some additional options. Through the View Full Report option, we could go into this evidence and see much more data collected:
As you can see in next evidence, there were much more information like Vulnerable Page URL, Execution Origin, User IP Address, Referer, Victim User Agent and Cookies:
In the DOM section, it was possible to download the DOM and see the web page captured from victim at the moment that script was executed:
After reporting this vulnerability, a humble reward was received.
HACKERONE REPORTS
To go deeper with Blind XSS, some reports from Hackerone about Blind XSS vulnerabilities are listed below:
CONCLUSION
Always you find a contact form, give it a try and inject payloads in order to find a Blind XSS. You don’t know if applications at the other side are vulnerable or not.
“Don’t give up. Great things take time“.