Preventing XSS requires separation of untrusted data from active browser content true or false

Introduction

For the past 15 years, the Open Web Application Security Project (OWASP) has helped organizations develop, purchase, and maintain trusted applications and APIs.

Nội dung chính Show

Introduction
What Is Cross-Site Scripting (XSS)?
Cross-Site Scripting (XSS) Case Studies
How Can I Prevent XSS Attacks?

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:

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.
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

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.

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.

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.

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.

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.

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.