About

XSS is the second most prevalent issue in the OWASP Top 10 and is found in around two-thirds of all applications.

Description

Cross-site Scripting, also known as XSS, is a way of bypassing the SOP (Standard Operating Procedure) concept in a vulnerable web application. It is a web security vulnerability that allows an attacker to compromise the interactions between users and a vulnerable application. It is one of many types of client-side injection attack, in which malicious scripts are injected into otherwise benign and trusted websites to run on the end user's device. It occurs when a vulnerability in an application enables an attacker to insert a malicious code—typically JavaScript—into the vulnerable website’s code, and it affects web-based applications and their end-users. The end user’s browser has no way to know that the script should not be trusted, and will execute the code. Because it thinks that it came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used within that site. These scripts can even rewrite the content of the HTML page.

Throughout this process, unsanitized or unvalidated inputs (user-entered data) are used to change outputs. Given that the malicious script runs client-side in the user’s browser (as opposed to server-side on the web server itself), the website isn’t the ultimate target, its users are. The attacker can use injected scripts to change the content of the website or even redirect the browser to another web page, for example, one that contains malicious code. Some XSS attacks do not have a particular target; the attacker solely exploits a vulnerability in the application or site, taking advantage of anyone unlucky. In many cases, XSS is performed in a more straightforward way, such as in an email message.

Types of Cross-Site Scripting Vulnerability

There are mainly three different types of XSS attacks.

The first type, stored XSS, also known as persistent XSS, is the more damaging. It occurs when a malicious script is permanently stored on the target servers and comes from the website's database, in a message forum, visitor log, comment field, etc.. Script is then injected directly into a vulnerable web application (e.g., via a comment field). Most frequent targets are websites that allow users to share content, including blogs, social networks, video sharing platforms, and message boards.

Reflected, or non-persistent XSS, where the malicious script comes from the current HTTP request. The injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request, embedded into a link, and only activated once that link is clicked on.

DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

Here you can find a comprehensive technical explanation of each type.

OWASP suggests the XSS categorisation as described in the OWASP Article: Types of Cross-Site Scripting, which covers all these XSS terms, organizing them into a matrix of Stored vs. Reflected XSS and Server vs. Client XSS, where DOM Based XSS is a subset of Client XSS.

XSS vs. SQLi

XSS is a well-known attack vector that injects malicious code into a vulnerable web application. It differs from other web attack vectors (e.g., SQL injections), in that it does not directly target the application itself, but its users. XSS vulnerabilities are recognized as less dangerous than SQLi vulnerabilities since most web browsers operate JavaScript in a very controlled environment. JavaScript has limited access to the user’s operating system and the user’s files - however, it can still be dangerous if misused as part of malicious content.

Overview

Web pages or web applications that are vulnerable to XSS are usually those that allow user input in login pages; search boxes; comment fields; sign-up forms; forms requesting name, address, phone, and credit card numbers; etc. A “read-only” or “brochureware” site can also be vulnerable to serious reflected XSS attacks.

Flaws are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

Consequences

A successful XSS attack can have overwhelming outcomes for an online business’s reputation and its relationship with its clients.

XSS enables an attacker to bypass the same-origin policy, designed to segregate different websites from each other and to execute scripts in the victim’s browser. It can cause a variety of difficulties for the end end-user that range in severity. The most critical XSS attacks include the disclosure of the user’s session cookie, allowing an attacker to impersonate that user and take over the account. The attacker can usually carry out any actions that the user is able to perform, and access any of the user's data. If the targeted user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data. As such, XSS attacks violate the first two (and potentially all three) of the foundational “CIA” security principles—confidentiality, integrity, and availability.

XSS vulnerabilities provide the perfect ground to escalate attacks to more advanced attacks, including cookie theft, installation of Trojan horse programs, keylogging, phishing, and identity theft. XSS can also be used in conjunction with other types of attacks, for example, Cross-Site Request Forgery (CSRF).

The result of an XSS attack is the same regardless of whether it is stored or reflected (or DOM Based). The difference is in how the payload reaches the server.

Detection

The best way to test application is by combining manual and automated techniques.

Static code analysis should be able to detect some XSS vulnerabilities. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript code. Identify every location where the submitted input from an HTTP request is returned in HTTP responses and test each one individually to determine whether suitably crafted input can be used to execute arbitrary JavaScript.

Potential impact

The impact of an exploited XSS vulnerability varies. It typically depends on the type of XSS vulnerability: the impact of XSS is moderate for reflected and DOM XSS, and severe for stored XSS, with remote code execution on the victim’s browser, such as stealing credentials, sessions, or delivering malware to the victim.

Furthermore, it depends on the characteristics of the application, its functionality and data, and the status of the compromised user.

Other factors include what, if any, further actions are required from the user, whether the attack is triggered reliably, and what exactly could potential attacker gain. If the site does not include private information, the impact is minimal.

More here.

Prevention

From a technical point of view, XSS is an injection-class vulnerability, in which the attacker manipulates the logic of the web application in a browser. So to prevent such vulnerabilities, one needs to thoroughly check any data that enters the application from the outside.*

The primary defenses against XSS are described in the OWASP XSS Prevention Cheat Sheet.

Preventing XSS requires the separation of untrusted data from active browser content. This can be achieved by:

• Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered.

• Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet ‘XSS Prevention’ has details on the required data escaping techniques.

• Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context-sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet ‘DOM-based XSS Prevention’.

• Enabling a Content Security Policy (CSP) as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).

Further steps you can take to prevent XSS attacks are:

• To mitigate the consequences of a possible XSS, set the HttpOnly flag for cookies so that such cookies will not be accessible via client-side JavaScript.

• Use proper response headers. Use the Content-Type and X-Content-Type-Options headers to ensure that browsers understand the responses as intended.

• Turn off HTTP TRACE support on all web servers.

• Input validation. Consider all user input as untrustworthy. Any user input that is used as part of HTML output carries a risk of an XSS.

• Sanitize input and HTML - application code should never output data received as input directly to the browser without checking it for malicious code.

• Encode data on the output to prevent it from being interpreted as active content. Use a proper escaping/encoding method depending on the output context: HTML, JavaScript, CSS, URL escape, etc.

• Use web application firewall (WAF).

• As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

• Provide suitable security training to all your developers, QA staff, DevOps, and SysAdmins.

• Never click on or share links that aren’t verified. Instead, look up the address or domain name manually and evaluate the search results.

Particular prevention techniques depend on the subtype of XSS vulnerability, on user input usage context, and the programming framework. However, there are some common principles that you should follow to keep your web application safe.

*https://www.ptsecurity.com/ww-en/analytics/knowledge-base/what-is-a-cross-site-scripting-xss-attack/

Cases

A stored XSS vulnerability was discovered in Steam’s chat client. The informative report can be viewed on HackerOne here.

Due to a lack of input validation from the search field on lert.uber.com, it was possible to obtain a Reflected XSS from the URL path as summarised by Uber’s security team.

A vulnerability in the DuckDuckGo search engine was identified and explained in this report.

More here.

____________________________________________________________________________________________

References:

[1] F5

[2] PortSwigger

[3] acunetix

[4] OWASP