This is the third installment in a series on Web Application Vulnerability Basics.
What Is Cross-Site Scripting?
Cross-Site Scripting, also known as XSS, is a web exploit that allows an attacker to inject malicious content (e.g., markup, or scripts) into a web application. Many cross-site scripting attacks utilize JavaScript, a client-side scripting language used by many websites and web applications. In an attack scenario, scripts are executed on a victim’s browser, possibly without the their knowledge, when a vulnerable webpage is visited. Attackers use XSS for session hijacking, stealing credentials, redirecting victims, and modifying how a page is rendered, and much more. XSS is widely prevalent and ranks as the second most common web application attack according to the OWASP Top 10 list for 2017.
How Does XSS Work?
For a cross-site scripting attack against a web application to be successful, two conditions must be met. One, the web application needs to accept some form of user input. This is usually data being passed in a web request, which the web app does not validate correctly. Two, this data is included, without proper sanitization, on the response back to the user’s browser where the attack is then triggered.
There are two types of cross-site scripting attacks: Reflected XSS and Stored XSS.
Reflected XSS
In a reflected XSS attack, an attacker’s payload (traditionally JavaScript) is injected into a legitimate web request, usually by tricking a victim into visiting a malicious URL or via a phishing attack. The payload is then included by the web server into the response to the victim, which gets executed by the user or browser.
A reflected XSS attack has no persistence and requires an attacker to trick the victim into submitting a malicious request themselves. Because of this, a reflected attack is less severe than a stored XSS attack due to the limited scope. However, a reflected XSS vulnerability is usually easier to find than a stored XSS vulnerability.
Stored XSS
In a stored XSS attack, an attacker will inject a payload (again, traditionally JavaScript) into a field that is stored by the web application and potentially displayed to one or more users. This can include profile names, photos, comments, and any other element within the application that displays user-provided input to other users. XSS can also be injected into HTML elements and triggered by a JavaScript event handler, such as the “onerror” attribute of an HTML image object. Any user who visits the page containing the malicious payload may then cause it to trigger. For example, if a profile photo element contains a malicious payload, this may fire every time a user of the web application visits the malicious profile.
The scope of a stored XSS attack isvast. Anyone visiting a page with an injected XSS payload could have their accounts compromised, data stolen, session hijacked, and more. Stored XSS attacks can lead to a full compromise of the web application if an administrator’s credentials are stolen. This attack could also be paired with cross-site request forgery to perform actions on behalf of victim without their knowledge.
XSS Mitigation Techniques
There are a few mitigation techniques that can be utilized to prevent XSS attacks. These techniques are simple but effective, and mainly focus on sanitizing and validating user input.
- Restrict and validate user input wherever possible.
- Utilize proper character escapes when inserting untrusted data (which all user supplied data should be treated as) into HTML elements, HTML attributes, JavaScript data values, CSS style blocks, and URL parameters.
- If markup is handled by web application (uses similar characters to HTML), use a HTML sanitization library.
- Utilize HttpOnly cookies to prevent JavaScript from reading or modifying site cookies and session hijacking via XSS.
- Implement a strict content security policy to limit scope of a successful XSS attack.
Conclusion
Protecting against XSS attacks is crucial to maintaining a secure web application. Keep XSS attacks in mind while developing and maintaining web applications and verify that XSS mitigation strategies are working as intended.
