CWE-79
CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
CWE-79, otherwise known as cross-site scripting (XSS) attacks, refers to a vulnerability that compromises end-users’ interactions with an application. XSS attacks concern developers of most languages — including C#, Go, Java, Python, and Scala, not just JavaScript — especially if there’s server-side handling of user-provided input.
It is #2 on the 2021 CWE Top 25 Most Dangerous Software Weaknesses list.
Why cross-site scripting is problematic
XSS attacks allow the malicious party to act as a legitimate end-user and perform actions the user would be able to, such as access their data, update their login credentials, and so on. If the end-user has privileged access to the app, the attacker could gain elevated access to the application.
How cross-site scripting works
Cross-site scripting occurs when a malicious party manipulates a compromised website into returning malicious JavaScript code to a legitimate user. When this code executes within the user’s browser, the malicious party can compromise a legitimate interaction between the website and the user.
More specifically, cross-site scripting happens when:
- The application accepts user input (for example, the web application accepts a web request).
- The web application utilizes the user input to generate a web page — because there’s no sanitization, the user-provided input could contain content the web browser can execute.
- Someone visits the web page; the browser renders the requested web page but includes the malicious code.
Types of XSS attacks
There are three primary types of XSS attacks:
- DOM-based (Type 0): This occurs when an application containing client-side JavaScript processes data and writes it to the webpage’s DOM.
- Reflected (Type 1): This occurs when the website receives data as part of an HTTP request, and it returns the included data immediately without any sanitization, verification, or other safety checks.
- Stored (Type 2): This occurs when the website receives data as part of an HTTP request, stores the data, and later returns the data in an HTTP response without any sanitization, verification, or other safety checks.
Mitigating XSS attacks
Because XSS attacks result from unexpected input supplied by an end-user, the primary mitigation is to sanitize and escape user input so malicious parties cannot provide problematic code. Depending on the needs of your application, you may also opt to accept no untrusted user input.
Some of the more common mitigation techniques include:
- Using a vetted library or framework to generate properly encoded/sanitized output (e.g., OWASP’s ESAPI Encoding module)
- Specify and use output encoding (e.g., ISO-8859–1, UTF-7, and UTF-8) that can be used by the downstream component that’s reading the data; without this, the component may opt for incorrect according, resulting in error
- Implement input validation; assume all input is malicious and require that all input is validated.
- Convert input; when working with a known set of input (e.g., file paths or page addresses), create a mapping and reject anything that isn’t included.
TL;DR
XSS attacks occur when user-supplied input is rendered and results in unexpected application behavior. There are three types of XSS attacks, but regardless of type, the malicious party’s end goal is to leverage the attack to perform malicious activities including, but not limited to:
- Sending malicious requests to the website on behalf of the legitimate user
- Launch phishing attacks to gain access credentials
- Directly stealing sensitive information
CWE-79 was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Katie Horne. Read the original post at: https://blog.shiftleft.io/cwe-79-41838f96007a?source=rss----86a4f941c7da---4
