2017 OWASP A7 Update: Cross-Site Scripting
For the past 15 years, the Open Web Application Security Project (OWASP) has helped organizations develop, purchase, and maintain trusted applications and APIs.
OWASP is a well-respected, open community known for many free resources, such as application security tools and standards, books on application security testing, secure code development, secure code review and several cheat sheets on many application security-related topics. However, OWASP is best known for regularly publishing its Ten Most Critical Web Application Security Risks list.
What Is Cross-Site Scripting (XSS)?
Cross-site scripting comes in three basic forms:
- Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Usually, this occurs when user input is stored on the vulnerable server (i.e., in a database, in a message forum, logs or an interactive field). In this case, the victim is able to retrieve the stored data from the web application without it being made safe to render in the browser.
- DOM XSS: In this attack the payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script, so that the client-side code runs in an “unexpected” manner. In a DOM XSS attack, the page itself does not change; in fact, the client-side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
A typical XSS attack may involve session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as fake login panels), attacks against the user’s browser such as malicious software downloads, key logging and other client-side attacks. The problem is, an XSS vulnerability is quite easy to detect and exploit, since its three forms can be identified with the help of automated tools and subsequently attacked with the help of freely available exploitation frameworks. The usual impact can be somewhat moderate for reflected and DOM XSS, but rather severe for stored XSS. This includes arbitrary remote code execution on the victim’s browser that can lead straight to credentials and sessions stealing, or creating a channel for delivering malware.
Cross-Site Scripting (XSS) Case Studies
Clicking on an infected page led victims strait to a bogus eBay authentication screen that, even for security-aware individuals, was very hard to spot as malicious. This resulted in a highly effective attack. As mentioned before, XSS vulnerabilities remain quite present. As of 2018, two of the most popular content management system (CMS) solutions released patches for fixing XSS.
How Can I Prevent XSS Attacks?
During OWASP’s Top Ten 2017 update, Cross-site scripting lost a few positions to other risks such as injection, broken authentication, sensitive data exposure, XML external entities (XXE), broken access control, and security misconfiguration. But the fact XSS still holds the seventh position means it cannot be overlooked.
On the bright side, fixing an XSS vulnerability is not an overwhelming task. As OWASP puts it, “While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack.” Preventing an XSS attack simply requires the segregation of untrusted data from active browser content, and that can be accomplished in a number of ways.
For instance, frameworks such as the latest version of Ruby on Rails and React JS automatically escape XSS by design. Also, as mentioned before, patching CMS solutions such as WordPress and Drupal is vital, as their most recent versions include fixes to any know XSS vulnerabilities.
Fixing DOM XSS requires the application of context-sensitive encoding when modifying the browser document on the client side. It is important to note sometimes this cannot be avoided. OWASP also publishes a cheat sheet called DOM-Based XSS Prevention with context sensitive escaping techniques that can be applied to browser APIs.
Another option is enabling a content security policy (CSP). This is a defense-in-depth mitigating control against XSS. It creates an additional security layer, enabling server admins to limit XSS entry vectors by specifying the domains that the browser should consider to be valid sources of executable scripts. In this case, a CSP compatible browser will be limited to executing scripts loaded in source files received from those whitelisted domains, completely ignoring all other scripts (including inline scripts and event-handling HTML attributes). In a more extreme approach, a CSP can globally disallow script execution on a site.
Once you decide on your XSS fixing approach, using a vulnerability scanner is the best way of confirming the issue been fixed.
To put it simply, it is not likely the XSS menace will disappear in the coming years. The best way to avoid a serious problem is, as usual, taking a proactive approach and implementing the necessary security controls. Otherwise, you may discover that, for example, every visitor to your site has being diverted to a malicious page.
Still need help? InfoSec Institute offers a two-day OWASP Top Ten Boot Camp offering a balanced mix of attention-getting lectures and hands-on secure coding activities. This Boot Camp was designed with the sole objective of providing professionals, such as web developers, web administrators and other IT and information security specialists, with an overview of the ten most critical web application security risks as defined by OWASP.