Blind XSS: The Ticking Time Bomb of XSS Attacks - AcunetixWhat 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 of the 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 of Blind Cross Site Scripting

The 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, etc.

Diagram describing a simple Blind Cross Site Scripting (XSS) attack.

A typical Blind Cross Site Scripting (XSS) attack. (Click to enlarge)

Blind XSS Target #1: 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 logon 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 logon form belongs to, checks out the logs for the day, and if those logs come up in 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.

Blind XSS Target #2: Forums / Message boards

Similarly 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 unsanitised topic titles may be loaded and consequently, the attacker’s script would be executed, calling back with stolen information, redirecting the user or cause 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 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 of 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 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 which 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.


Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.

  • Is the only difference between blind XSS and persistent XSS that you’re saying the attacker doesn’t know where their attack is stored? They just know that it is stored? I don’t really see much difference here from simple persistent XSS.

    • Hi,

      Blind XSS is actually a stored (persistent) XSS. The main difference is that the XSS payload is injected in one web application and gets triggered from a completely different web application. The examples in this article illustrate this type of attack further.

    • The XSS payload may not execute making the attacker think that the Application is not vulnerable, but this attempt could be stored in error log files etc. And down the line maybe days, weeks or even years the log files may be handled differently and in turn executing the malicious payload. It is basically stored XSS but the attacker is blind to when it will execute or if it will execute at all.

  • is an excellent post, which explains well and blind easy XSS attack! 🙂

  • I really hope developers start taking XSS seriously. The creativity with which exploits are being released is growing very quickly. It’s really only a matter of time before blind attack or scans become popular and a real issue.

    At present there are XSS vulns in some of the most respected websites so the possibility for attack is huge!

  • I have a PHP Web Application, which contains a contact form. When I scan it with Acunetix, I get Blind XSS report. I prevented script tags in my PHP code and when I try to put script tags inside my contact form field, then click send button, I get a message, saying that “This is not permitted”.

    However, when I run again Acunetix scan, I get the same Blind XSS report. What should I do? Do I need to redirect to 403, when a contact form field contains script tag?

    • No don’t use 403 – This is “Unauthorised”. Some browsers won’t even render a response body with this error code. Use 400 and represent your form in the response body.

      Also, ensure your validation is done is done “server” side. Client side validation will not protect your application, and will not deceive Acunetix in to thinking your form is secure; Your front end script will not apply to the engine.

  • Comments are closed.