XSS-Fatigue: Realities and Pitfalls
Cross-Site Scripting was ‘discovered’ in 1999, and since then, has appeared in just about every ‘top-ten most common vulnerabilities’ list. The frequency and longevity of XSS in headlines, POCs and vulnerability databases over the past 10+ years have thrown us into ‘XSS-fatigue.’ In our own annual report this year, we reported that of all vulnerabilities submitted through Bugcrowd programs, over 25% were classified as XSS. In this post, we’ll explore the idea of XSS-fatigue, why XSS bugs are still so prevalent, and some examples in which XSS were incredibly high impact, proving that XSS-fatigue is founded not in quality, but perception.
Why has XSS-fatigue happened?
The security community–consultants and researchers–have been submitting XSS in reports for a long time. But instead of proving the impact of an XSS vulnerability and exploiting a full attack by taking over accounts etc., the industry has standardized on a JavaScript pop-up or prompt box. In short, the industry has written off XSS as low-hanging fruit, partially because it has been around for so long, and also because bug reports are downplayed.
In reality, however, this isn’t how it happens in the real world. There are many of exploit frameworks that rely on XSS, including ransomware attacks, nation-state attacks, and more. This fatigue isn’t fully due to lack of impact, but because after ten years it has become passe. Below are some examples of XSS bugs that have real, impactful implications.
Bugcrowd’s classifications of XSS
In March, we issued our first update to our Vulnerability Rating Taxonomy, dividing our Cross-Site Scripting (XSS) entries to provide additional granularity that captures priority variations for XSS within applications with multiple user privilege levels.
Read more about the details, and why we issued this update in the report itself.
Real-Life Examples:
Example #1:
The Company: Internet media company
The Bug: The website in question didn’t require the old password to reset the new password, so the attacker was able to use the XSS found in one place to update the password with Cross Site Request Forgery (CSRF). This combination led to not only account takeover via session hijacking, but also a full password reset by the attacker..
Impact: Because of the sensitivity of data stored within user accounts, including credit card information and addresses, this could have led to a massive privacy breach. TWhile this type of vulnerability on its own would have been classified as Priority 3 (P3) Reflected XSS based on our VRT, combined with CSRF and weak security controls, the customer considered it as a Priority 1 (P1) vulnerability.
Example #2:
The Company: Multiple organizations w/ multi-tenant CMS
The Bug: Privilege Escalation and Remote Code Execution via XSS. Privilege escalation is common with multi-tenant systems–systems with multiple roles within an application.
In this example, a researcher found an XSS that would allow an attacker to force administrative users to promote non-admin users to an admin role. In this case, the admin had virtually unlimited access within in a content management system. After using XSS to allow for silent and automatic account upgrading to admin, the attacker was then able to to use his new account to inject more code, including adding a web shell to the server to take over the server.
Impact: Some will not accept this bug because they believe it requires a phish on the part of the admin, which is unlikely to happen, but in most cases, admins are just as susceptible to phishing and XSS as anybody else. In this case, the attack in the JavaScript was so cleverly crafted with CSS modification and left all the hooks and codes in the background, so the admin never even knew what was going on. This wouldn’t have been possible without XSS.
Example #3:
The Company: Chat program
The Bug: This bug utilized XSS in a web-based chat program. Because this software was available on both the web and installable on PC’s, the researcher was able to use the XSS to execute code on the installed version of the software.
Impact: Eventually, using a chain of exploits, this could allow an attacker to control chat user’s computers who had never used the web version. After the complete exploit chain, an attacker could steal files, web-based accounts, and use the user’s internet connection for nefarious purposes.
Example #4:
The Company: Communications company
The Bug: Blind XSS is a vulnerability where an attacker sends cross-site scripting attacks into a form that isn’t expected to return any result right away. In this example, the researcher sent the XSS into an interactive website chat to the company’s help/support system. Eventually, this attack got posted to an internal queue and executed, calling home to the researcher and allowing him to control a browser that was on the internal network of the target company.
Impact: Blind XSS can have a variety of impacts. Here the researcher completely traversed several security functions the website had and ended up controlling a browser that the help desk technician sat in front of. This kind of access to the internal network and a privileged user can be the start of a complete network compromise. Blind XSS is a hot topic right now due to its impact and the argument that some think it is a form of advanced phishing. This actually is not the case, as the original factor here is that website itself allowed the attacker to send through malicious XSS code. The initial website, and internal websites too, should always practice good input validation and output encoding.
To hear more examples of XSS and how they can be incredibly impactful, listen to last month’s Big Bugs podcast with Jason Haddix, Bugcrowd’s Head of Trust and Security.
Additionally, download our State of Bug Bounty Report to read more about why XSS makes up over 25% of all bug types submitted to Bugcrowd bug bounty programs in our newly issued addendum to the report.
