XSS Vulnerabilities
XSS Vulnerabilities
The malicious scripts are executed within the end user’s browser and enable various
attacks, from stealing the end-users session to monitoring and altering all actions
performed by the end-user on the affected website.
This includes altering all user actions on that website since the browser does not
know that this script cannot be trusted. Because this script is trusted, it can access,
e.g., cookies or session tokens or even alter the content of an HTML Page.
In a Stored XSS example, the script might have been submitted via an input
field to the web server, which did not perform a sufficient validation and stores
the script persistently in the database. The consequence of this might be that
this script is now being delivered to all users visiting the web application and,
e.g., able to gain access to the user’s session cookies.
2
Reflected Cross-Site Scripting (Non-Persistent)
In a Reflected XSS example, the input of a search form is reflected on the page
to show what the search key was. An attacker may craft an URL that contains
malicious code and spread the URL via e-mail or social media. A user who
clicks on this link opens the (valid) web application, which then runs the
malicious code in the user’s browser.
3
DOM-Based Cross-Site Scripting
DOM stands for Document Object Model and is an interface to web pages. It is
essentially an API to the page, allowing programs to read and manipulate the
page’s content, structure, and styles.
DOM-based XSS attack may be successfully executed even when the server
does not embed any malicious code into the webpage by using a flaw in the
JavaScript executed in the web browser.
For example, if the client site JavaScript modifies the DOM tree of the webpage
based on an input field or GET parameter without validating the input,
malicious code can be executed.
4
There are many other new types of XSS listed here -
Although it is technically not a true XSS vulnerability due to the fact it relies on
socially engineering a user into executing code rather than a flaw in the affected
website allowing an attacker to do so, it still poses the same risks as a regular XSS
vulnerability if properly executed.
Mutated XSS happens when the attacker injects something that is seemingly safe
but is rewritten and modified by the browser while parsing the markup. This makes it
extremely hard to detect or sanitize within the website’s application logic. An
example is rebalancing unclosed quotation marks or even adding quotation marks to
unquoted parameters on parameters to CSS font-family.
The big deal about this attack is that it bypasses most of the existing XSS filters and
sanitizers.
Attackers in BXSS inject their payload “blindly” on web pages that are likely to save
their payload into the database (like contact forms, logs, etc.). Then, the attacker
waits for a server-side user or team member [who deals with website databases] to
open or trigger that script or payload to execute.
5
Risk of XSS Vulnerabilities
Because a Cross-Site Scripting attack infects the user’s browser, you might think it is
pretty harmless to your web application. But, unfortunately, nothing could be further
from the truth:
An attacker could change parts of the web page or send the user to another
(potentially malicious) web page through the injected script. Your user will notice and
be less likely to go on using your web application in any way.
Cross-Site Scripting vulnerabilities are hard to identify and remediate.What can you
do so? To prevent XSS attacks, treat all user input as potentially malicious and
follow some programming guidelines: