Blind XSS Impact

What is Blind XSS?

Blind XSS is a flavor of cross-site scripting (XSS), where the attacker “blindly” deploys a series of malicious payloads on web pages that are likely to save them to a persistent state (like in a database, or in a log file). Then, without knowing any details about where the payloads have ended up, or if (and when) they are going to be executed, the attacker waits for the payloads to be pulled out of storage and rendered on a web page loaded by a user. Hence, unlike most XSS attacks, which are non-persistent, and rely on immediate response pages generated from the data input by the attacker in a web form or HTTP query, Blind XSS is a persistent type of XSS that relies on vulnerabilities in the code of the target web pages, which allow malicious scripts, inserted into web controls, to be saved by the server in a database or web site file. These are then “served” to other users as part of HTML page responses, without begin “sanitized” first.

The distinction of the Blind XSS attack is the fact that the attacker does not know where the payload will end up and if, or when, it will get executed. Hence, in order for the attack to succeed, the attacker needs to make sure that enough payloads are deployed, and that the payloads are crafted in such a way as to be effective in time, know where to call back and how to sign off the results. At the same time, the attacker needs to implement technology to listen for eventual call backs from the payloads deployed.

Common Targets 

A most common target of Blind XSS is obviously any web page that gets user input and saves it somewhere for later viewing (by others) – logon forms, log viewers, customer service applications, exception handlers, forums/message boards, feedback forms, chat windows

Logon forms

Logon forms usually take the input user name string and save it to a log file which can be viewed, at a later stage, from a web page. Hence, a failed logon, with a malicious script entered in the “user name” field of the logon form, will cause the server to save an entry into the log which will have the malicious script as the “user name”. An attacker can perform several such login attempts in order to get the malicious script(s) into the log database or log file. Later on, if an administrator of the website (or web application) that the login form belongs to, checks out the logs for the day, and if those logs come up on a web page, the malicious script may get executed and call back to the attacker with the desired information. 

Typical targets in this scenario are web-based applications that require authentication, web management consoles for appliances, etc. Typical damage ranges from stolen credentials to unauthorized access to the data manipulated by the application (or appliance) and denial of service. Typical user targets are the administrators and the aim usually is security related.

Forums & Message boards

Similar to the previous scenario, attackers can place the malicious scripts within the topic title in a forum or message board. Again, most commonly, the server will save their post to a database, and the stored information can get exposed to other viewers, like the moderators over a period of time. In this scenario, the script may get sanitized 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 unsanitized 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 message boards, who load forum content from management web sessions in order to perform administrative tasks and the aim is again, security related.

Detecting and Preventing Blind XSS Attacks

The best cure is prevention; therefore the best way to defend against Blind XSS attacks is to make sure that your website or web application is not vulnerable. The most effective way to accomplish this is by having web developers review the code and ensure that any user input is properly sanitized. If this is not done, there is a risk that user input does not get scraped off any scripting tags before being saved to storage or served to the user’s browser, and consequently, your website or web application might be vulnerable to XSS, including Blind XSS attacks.

It is good coding practice to never trust data provided by the user. In order to eliminate all risks, you need to implement sanitization of the user input before it gets stored, and also, as a second line of defense, when data is read from storage before it is sent to the user’s browser.

Next, you need a specialized tool that performs innocuous penetration testing, which apart from detecting the easy-to-detect XSS vulnerabilities, also includes the ability to detect Blind XSS vulnerabilities which might not expose themselves in the web application being scanned (as in the forum example). If you do not have access to the code or the time to check millions of lines of code, you can use such a tool in order to determine if your website or web application is vulnerable to Blind XSS attacks, and if positive, you will need to address this with your software provider.

The difficulty in detecting Blind XSS without a code review comes from the fact that this type of attack does not rely on vulnerabilities in the third-party web server technology or the web browser; vulnerabilities that get listed or you can scan for and patch. This attack exploits vulnerabilities introduced by the developers in the code of your website or web application. So even 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. In addition to this, Blind XSS attacks are even more difficult to detect since the payload is executed on a completely different web application than where it was injected.