Non-Persistent vs Persistent XSS Vulnerabilities
Cross-site scripting (XSS) vulnerabilities can be classified into two types:
- Non-persistent (or reflected) cross-site scripting vulnerabilities occur when the user input is reflected immediately on the page by server-side scripts without proper sanitization. Reflected XSS vulnerabilities are the most common type.
- Persistent (or stored) cross-site scripting vulnerabilities occur when user input provided by the attacker is saved by the server, and then permanently displayed on pages returned to other users in the course of regular browsing, without proper HTML escaping. Stored XSS is much more dangerous compared with the reflected XSS because the attacker payload remains on the vulnerable page and any user that visits this page will be exploited. A persistent XSS vulnerability can be transformed into an XSS worm (like it happened with the Samy XSS worm that affected Myspace a few years ago).
Blind XSS Vulnerabilities
Blind XSS vulnerabilities are a variant of persistent XSS vulnerabilities. They occur when the attacker input is saved by the server and displayed in another part of the application or in another application. For example, an attacker injects a malicious payload into a contact/feedback page and when the administrator of the application is reviewing the feedback entries the attacker’s payload will be loaded. The attacker input can be executed in a completely different application (for example an internal application where the administrator reviews the access logs or the application exceptions).
Example of applications where Blind XSS vulnerabilities can occur:
- Contact/Feedback pages
- Log viewers
- Exception handlers
- Chat applications / Forums
- Customer ticket applications
- Web Application Firewalls
- Any application that requires user moderation
These types of vulnerabilities are much harder to detect compared to other Reflected XSS vulnerabilities where the input is reflected immediately. In the case of Blind XSS, the attacker’s input can be saved by the server and only executed after a long period of time when the administrator visits the vulnerable Dashboard page. It can take hours, days or even weeks until the payload is executed. Therefore, this type of vulnerabilities cannot be tested as the other type of XSS vulnerabilities.
Blind XSS is a special type of stored XSS in which the data retrieval point is not accessible by the attacker – for example, due to lack of privileges. This makes the vulnerability very difficult to test for using conventional techniques. In many cases, there is no hint whatsoever in the application’s visible functionality that a vulnerability exists. Since security testers are in the habit of spraying target applications with alert(1) type payloads, countless admins have been hit by harmless alert boxes, indicating a juicy bug that the tester never finds out about. Due to the inherent difficulty in detecting blind XSS vulnerabilities, these bugs remain relatively prevalent, still waiting to be discovered.
It is a classic stored XSS, however its exploitation technique is a little bit different than the majority of classic Cross-Site Scripting vulnerabilities. Instead of sending the vulnerable URL to website administrator with XSS payload, an attacker needs to wait until website administrator opens his administrator panel and gets the malicious script executed. This is happening because the vulnerable script [that accepts user-supplied input without filtration] is different from the script that displays the input to the victim. In other words, blind XSS is a classic stored XSS where the attacker doesn’t really know where and when the payload will be executed.
If we are refer about open source web applications, such as the above-mentioned example, it’s not really appropriate to speak about ‘blind’ XSS, as we already know where the vulnerability will be triggered and can easily trick our victim to open the malicious link. Nevertheless, these vulnerabilities have common exploitation techniques, as the attacker knows in advance the URL with malicious payload.
Authentic blind XSS are pretty difficult to detect, as we never knows if the vulnerability exists and if so where it exists. However, during extensive penetration tests or continuous web security monitoring, blind XSS can be detected pretty quickly – it’s enough to create a payload that will communicate the vulnerable page URL to the attacker with unique ID to confirm that stored XSS vulnerability exists and is exploitable.
Practically speaking, blind XSS are difficult to exploit and do not represent a high-priority risk for majority of web applications. Nevertheless, in case of success, blind XSS can be a pretty dangerous logic bomb that may compromise your system when you don’t expect anything bad. Therefore, when accepting and storing any user-supplied input – make sure you have properly sanitized it.
Blind cross-site scripting (XSS) is an often-missed class of XSS which occurs when an XSS payload fires in a browser other than the attacker’s/pentester’s. This flavour of XSS is often missed by penetration testers due to the standard alert box approach being a limited methodology for finding these vulnerabilities. When your payloads are all <script>alert(1)</script> you’re making the assumption that the XSS will fire in your browser, when it’s likely it will fire in other places and in other browsers. Without a payload that notifies you regardless of the browser it fires in, you’re probably missing out on the biggest vulnerabilities.
In band detection is impossible for Blind XSS vulnerability and the main stream remain make use of out-of-band detection for interactive activity monitoring and detection.
Poisoning the Well and Ticky Time Bomb wait for victim
One of the interesting things about using a blind XSS tool (example, XSS Hunter) is that you can sprinkle your payloads across a service and wait until someone else triggers them. The more you test for blind XSS the more you realize the game is about “poisoning” the data stores that applications read from.
For example, a users database is likely read by more than just the main web application. There is likely log viewing apps, administrative panels, and data analytics services which all draw from the same end storage. All of these services are just as likely to be vulnerable to XSS if not more because they are often not as polished as the final web service that the end customer uses.
To make a physical comparison, blind XSS payloads act more like mines which lie dormant until someone triggers them (i.e. ticky time bomb).
Common Targets of Blind Cross Site Scripting (XSS)
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.
While the standard remediation for XSS is generally contextually-aware output encoding, you can actually get huge security gains from preventing the payloads from being stored at all. When you do proper output encoding, you have to do it on every system which pulls data from your data store. However, if you simply ensure that the stored data is clean you can prevent exploitation of many systems because the payload would never be able to be stored in the first place. Obviously, ideally you would have both, but for companies with many services drawing from the same data sources you can get a lot of win with just a little filtering.
E-SPIN carry and represented web vulnerability scanner (WVS) have the method and technique to detect out-of-band blind XSS, please refer each product / brand line for specific instruction and deploying recommendation, or consult with our solution consultant.