Recently, security researcher Matthew Bryant discovered a blind cross-site scripting (BXSS) vulnerability in GoDaddy’s customer support portal —that is the portal accessible only to GoDaddy customer service representatives, not customers.
New post: Poisoning the Well – Compromising GoDaddy Customer Support With Blind XSS – https://t.co/uEJWPU8Y4O
— mandatory/MattBryant (@IAmMandatory) May 8, 2016
After disclosing the vulnerability to the domain and hosting giant, the vulnerability was eventually resolved after some three months of it being reported.
It’s important to consider the possible ramifications of a blind XSS vulnerability—an attacker would have potentially been able to access GoDaddy’s internal customer service portal and potentially modify account information, transferring domain names, and even deleting a customer’s account altogether.
What is Blind XSS exactly?
Blind cross-site scripting (BXSS) is a variation of stored XSS, where the injection point and the execution point are different. It’s harder to find and certainly requires a different methodology than testing for stored (non-blind), reflected, or even DOM-based XSS.
Typically, with stored XSS, the payload is executed on the same page it was injected in. The classic example of this is of a comment form on a blog. Let us assume that a blog web application accepts user input from a comment form, which gets stored in a datastore (typically a database). For the blog to be vulnerable to stored XSS, the application needs to output the contents of the comment stored in the database without properly encoding the user-supplied input before rendering it into the page.
Blind XSS is very similar to stored XSS, because it is a variation of stored XSS. The only difference between the two vulnerabilities infact is that the injection point and execution point are not on the same.
This detail however is very important—it implies that input from web application ‘A’ could effect a completely separate web application ‘B’ if application ‘B’ makes use of data injected from application ‘A’. This is referred to as an out-of-band vulnerability, since an attack does not use the same channel (in this case, the same HTTP request/response) to conduct the attack—instead, the payload is delivered via application ‘A’ and it eventually executes in application ‘B’ when it is loaded in someone’s browser.
To make matters worse, the stored XSS payload can sit in the database for an unknown period of time, until it executes in a user’s browser whilst using application ‘B’. This is referred to as a delayed vulnerability, because the response to the input submitted in an attack is not necessarily immediate.
Testing for Blind XSS
This combination of out-of-band and delay makes it impossible for an attacker to discover blind XSS using conventional methods. Instead, an attacker would need to alter the XSS payload to connect to an intermediary service which is always listening to connections being made to it, thus revealing the existence of the BXSS vulnerability, after which, the attacker can proceed with escalating the attack . This infact, is the premise to how Acunetix AcuMonitor can be used to detect out-of-band, delayed vulnerabilities such as blind XSS.
Acunetix AcuMonitor acts as an intermediary service between the Acunetix Vulnerability Scanner and the location where the out-of-band vulnerability executes. As soon as AcuMonitor receives a callback from a payload being executed, it looks up who the identifier in the payload belongs to and notifies that Acunetix Vulnerability Scanner user.
To such an extent, it is not possible to detect blind XSS unless someone (or something) executes the payload (on application ‘B’) in a browser. Therefore, in order to fully test for blind XSS, unless you want to rely on a user coming across a payload inadvertently (which may or may not happen), you might want to map out the applications that are reading data generated by the application being scanned. These can include Reporting, Log Analysers, CRM systems and 3rd party web applications which might be reading data using some API.
Use the Acunetix Crawler to crawl any other web applications after application ‘A’ has been scanned.
Since the Acunetix Crawler can execute JavaScript, it will automatically trigger a blind XSS payload if one exists. Of course there may still be some ‘blind spots’ with this approach, however it is a semi-automated approach that makes it more practical to find blind XSS vulnerabilities.
It is important to note that AcuMonitor itself does not store or have access to any vulnerability information itself. The only thing being transferred is an identifier in order for AcuMonitor to know who to contact in the event of a payload executing. The injection point is stored on the scanner’s end and the identifier can be used to find the original injection point..
Of course in the example above we are illustrating blind XSS, however, the same methodology can be extended to detect other out-of-band vulnerabilities automatically. Such XML External Entity Injection (XXE), Server Side Request Forgery (SSRF), Out-of-Band SQL Injection (OOB SQLi), Out-of-Band Remote Code Execution (OOB RCE), Host Header Injection, Email Header Injection and Password Reset Poisoning.