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).
Overview of Blind Cross Site Scripting
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.
Detect Blind Cross-Site Scripting Vulnerabilities with AcuMonitor
Acunetix Web Vulnerability Scanner version 9 introduces a new service named AcuMonitor, which is designed to detect this type of vulnerabilities (and other new categories of vulnerabilities that could not be detected before).
The AcuMonitor service detects Blind XSS vulnerabilities as described below:
- User registers to the AcuMonitor service by providing an email address for notifications.
- Acunetix WVS injects various script payloads into the tested web application (into GET/POST variables, HTTP headers, cookies, URLs, …)
- If the web application is vulnerable to Blind XSS, the script payload is saved into the database.
- When the web application administrator visits the vulnerable page, the previously injected script payload is executed. This script will be loaded from an AcuMonitor server that gathers basic information about the vulnerable page.
- AcuMonitor sends a notification email to the registered user. The notification email contains the information gathered about the vulnerable page and information about the HTTP request that injected the script payload.
- The user can use the information in the notification email to lookup the original request from Acunetix WVS.
Detecting a Real-Life Blind XSS Vulnerability in a WordPress plugin
The Count per Day WordPress plugin was vulnerable to a Blind XSS vulnerability that was fixed in version 3.2.6. The vulnerability occurred because the script counter.php was not properly sanitizing the HTTP Referrer header. This plugin was saving to the database the last user referrers and displaying this information on the WordPress Dashboard plugin page. To exploit this vulnerability an attacker would need to send a request to any page with a custom HTTP Referrer header and wait for the administrator to visit the WordPress Dashboard page. At this point the attacker can steal the WordPress cookies or perform other attacks.
After the vulnerable WordPress installation was scanned with Acunetix Web Vulnerability Scanner version 9 (with AcuMonitor service enabled), we logged into the WordPress Dashboard page. Various script payloads were injected into the application during scanning.
At this point, the injected script payloads were executed and AcuMonitor started to get information about the vulnerable page and prepared a notification for the user. In a few minutes the user received a notification email about the Blind XSS vulnerability with information on how to reproduce this vulnerability.
The notification email contained the following details:
AcuMonitor extracted various information which can be used by the user to reproduce the vulnerability.
The alert details include the IP address, user-agent, page URL, page title, the Referrer header and the cookies used when visiting the vulnerable page. Also, a screenshot was generated by the injected code.
The alert also contains an attachment that, when opened, will load the HTTP request that injected this script payload. The initial HTTP request can also be loaded using the Request ID information in the AcuMonitor settings page.
From the initial HTTP request, the user can easily identify that the injection vector is the referrer header, and can use this information to fix the vulnerability (or in this case contact the WordPress Plugin’s developers).
Since Blind XSS vulnerabilities are much harder to detect compared with reflected ones they are not usually uncovered and fixed, leaving the website vulnerable.