A XSS (Cross-Site Scripting Attack) is a type of injection attack where malicious scripts are injected into web pages. This security vulnerability can lead to takeovers of accounts and stealing of sensitive tokens. XSS is classified into three families of the process used to compromise an application: Reflected, Stored, and DOM-based XSS.
Reflected XSS (AKA Non-Persistent or Type I) is when an application receives in put in an HTTP request and embeds that input within the immediate response in an unsafe way.
Suppose a book website has a search function where the user supplies a search term in a URL parameter. Searching for the book “title” would send a request like this:
https://book-site.com/search?term=title
The application echoes the give search term in the response to this URL:
<p>Your search: title</p>
Assuming the application doesn’t perform any other processing of the data, an attacker could then construct a payload like this:
https://book-site.com/search?term=<script>/*+malicious+script...+*/</script>
This URL results in this response:
<p>Your search: <script>/* malicious script…*/</script></p>
If such a URL is shared with and visited by a target,the attacker could potentially take over the Victim's session.
To find Reflected XSS vulnerabilities on your website, you can use a web vulnerability scanner. Or, to do this manually, you can individually test every entry point for data within the web app’s HTTP requests and eventually test candidate XSS payloads that might deliver working XSS attacks.
Stored XSS (AKA Persistent or Type II) is when an application receives input in an HTTP request, stores that input, and embeds it in a later response in an unsafe way.
Suppose our book website has the functionality for a user to comment on photos posted by the public. Commenting “great story” on an image would send a request like this:
https://book-site.com/poster1?add_comment=Love+this+author
Once this comment is submitted, any visitor to the blog post will receive the following within the application’s response to this URL:
<p>Love this author</p>
Assuming the application doesn’t perform any other processing of the data, an attacker could then construct a payload like this:
https://book-site.com/poster1?add_comment=<script>/*+malicious+script...+*/</script>
This malicious script would be stored as a comment, then whenever a user would visit that post, the code would automatically execute.Any user who visits that post is a target.
To find Stored XSS vulnerabilities on your website,you can use a web vulnerability scanner. Or, to do this manually, you can testall entry points that an attacker-controllable data could enter the web app’s processing through as well as all exit points where such data might appear inthe app’s responses.
The Document Object Model (DOM) is a web browser's hierarchical representation of the elements on the page. Websites can use JavaScript to manipulate the nodes and objects of the DOM, as well as their properties. DOM manipulation is fundamental for modern website functionality.However, a website’s JavaScript that handles data in an unsecure way can lead to various attacks.
DOM-based vulnerabilities arise when a website contains a source (JavaScript that accepts data which is potentially attacker-controlled) and passes it into a sink (possibly dangerous JavaScript function or DOM object if fed malicious data).
DOM-based XSS (AKA Type-0) is typically when JavaScript takes data from an attacker-controllable source, such as the URL, and propagates it to a sink supporting dynamic code execution such as eval() or innerHTML. This can enable attackers to execute malicious JavaScript that allows them to hijack other users’ accounts.
To find DOM XSS vulnerabilities on your website, you can use a web vulnerability scanner. You can also manually test for DOM-based XSS scripting by using a browser with developer tools, working through and testing each possible source individually.
To most effectively evade DOM-based vulnerabilities, avoid allowing data of an untrusted source from being written to the HTML document or from dynamically altering the value that is transmitted to any sink. If the web app’s function makes this behavior unavoidable, defenses should be implemented within the client-side code. For many cases, relevant data can be validated on a whitelist basis. For others, the data should be sanitized or encoded. This can get tricky, possibly involving a complex sequence of JavaScript escaping,HTML encoding, and URL encoding.
For a while, the three types of XSS were commonly seen and referring to as separate, but in reality, they overlap. About mid2012, the community proposed using two new terms to more distinctly organize XSS into types: Server and Client XSS.
Server XSS is when untrusted user-supplied data is included in a server-generated HTTP response. The source of this data could be from the request (Reflected Server XSS) or a stored location (stored Server XSS). The vulnerability is entirely server-side code while the browser is simply rendering the response and executing any valid script embedded in it.
Client XSS is when untrusted user-supplied data is used to update the DOM with an unsecure JavaScript call (where it can be used to introduce valid JavaScript into the DOM). This data could source from the DOM or by the server (via an AJAX call or page load), the ultimate source of the data either being a request (Reflected Client XSS) or a stored location on the client or server (Stored Client XSS).
With these definitions, DOM-based XSS is seen as a subclass of Client XSS, the source of the data being somewhere in the DOM as opposed to the server.
Here are some of the sensitive actions an XSS attacker can perform:
Here’s a checklist to prevent XSS attacks:
Now you know the types of XSS, their dangers, and howto mitigate them. Check out our other posts below and stay tuned to our blog!
