2017 OWASP A7 Update: Cross-Site Scripting

Introduction

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)?

With a presence going back to the early days of OWASP’s 2004 list, the risk of cross-site scripting (XSS) remains a significant threat in 2017, as it can be found in around two thirds of all applications. An XSS flaw can happen whenever an application includes untrusted data in a new web page without adequate validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. This allows attackers to execute scripts in the victim’s browser that can hijack user sessions, deface web sites or even redirect the user to a malicious site.

Cross-site scripting comes in three basic forms:

1. Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output that, if successfully exploited, can lead to arbitrary HTML and JavaScript code execution in the victim’s browser. In reflected XSS, the user input is instantly returned by the web application in an error message, search result or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data.
2. 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.
3. 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

A notorious cross-site scripting flaw was the case with eBay’s stored XSS vulnerabilities. It was discovered in 2015, but was still being exploited in 2017 to steal credentials. For cybercriminals, exploiting this vulnerability was trivial, as eBay’s website allowed the inclusion of malicious JavaScript in auction descriptions. Early attacks involved abusing this vulnerability to inject malicious redirect code on high-value listings (like vehicles) and stealing login credentials from eBay members. As more accounts were compromised, the attacks expanded into lower-value item listings. Legitimate listings from reputable, and yet compromised, eBay accounts were also affected.

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.

Also important is escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS or URL). This will fix reflected and stored XSS vulnerabilities. Hot tip: use the OWASP cheat sheet on XSS prevention, as it provides details on data escaping techniques.

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.

Conclusion

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.

Sources

Stored XSS in ebay messages filenames

Hackers still exploiting eBay’s stored XSS vulnerabilities in 2017

WordPress 4.9.2 Security and Maintenance Release

Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-001

OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet

OWASP DOM based XSS Prevention Cheat Sheet

Content Security Policy (CSP)