Attackers will send suspicious scripts to websites, which can obtain website cookies, session tokens, or other sensitive information saved by the browser, and even rewrite the content of HTML pages.
Background
There are different types of XSS vulnerabilities. The first ones discovered were stored XSS and reflected XSS. In 2005, Amit Klein discovered DOM-based XSS.
Reflected XSS, also known as unsustainable XSS, occurs when user input is immediately returned by a web application in an error message, search results, or any other response that contains some or All are entered without rendering this data securely in the browser and without permanently storing user-supplied data. In some cases, user-supplied data may never even leave the browser.
Stored XSS is also called sustainable XSS. Stored XSS usually occurs when user input is stored on the target server, such as in databases, forums, visitor logs, comment fields, etc. The victim is then able to retrieve the stored data from the web application,
There is no need to render this data securely in the browser. With the advent of HTML5 and other browser technologies, we can envision attack payloads being stored permanently in the victim’s browser, such as in an HTML5 database, and never being sent to the server at all.
DOM-based XSS (or “Type 0 XSS” as it is called in some texts) is an XSS attack in which the attack payload is executed by modifying the DOM “environment” used by the original client script in the victim’s browser , so that the client code will behave in an “unexpected” way. That is, the page itself (i.e. the HTTP response) does not change, but the client-side code contained in the page executes differently due to the malicious modifications that occurred in the DOM environment.
Different types of XSS
The above three XSS classifications overlap. In 2012, the research association proposed to start using new words to identify XSS.
- Server side XSS
- Client-side XSS
Server-side XSS occurs when a server-generated HTTP response contains data provided by an untrusted user. The source of this data may be the request or the storage location. So you can have both reflected server-side XSS and stored server-side XSS. In this case, the entire vulnerability is in the server-side code, and the browser simply renders the response and executes the valid script embedded within it.
Client-side XSS occurs when untrusted user-supplied data is used to update the DOM using unsafe JavaScript calls. JavaScript calls are considered unsafe if valid JavaScript can be introduced into the DOM. The source of this data may be the DOM, or it may be sent by the server (via AJAX call or page load). The ultimate source of the data may be from the request, or from a storage location on the client or server. So you can have both reflected client-side XSS and stored client-side XSS. With these new definitions, the definition of DOM-based XSS has not changed. DOM-based XSS is just a subset of client-side XSS, where the source of the data is in the DOM rather than coming from the server.
Original text: Types of XSS | OWASP Foundation
Recommended server-side XSS defense method
Server-side XSS is caused by the inclusion of untrustworthy data in HTML responses. The simplest and most powerful way to defend against server-side XSS is Context-sensitive server-side output encoding
Input validation and data sanitization can also prevent server-side XSS, but are difficult to get right.
Recommended client-side XSS defense methods
Client-side XSS occurs when untrusted data is used to update the DOM in unsafe JavaScript calls. The simplest and most effective defense against client-side XSS is:
Use a secure JavaScript API
However, developers often don’t know which JavaScript APIs are safe, let alone which methods in their favorite JavaScript libraries are safe. Dave Wichers covered which JavaScript and jQuery methods are safe and unsafe in his DOM XSS talk at OWASP AppSec USA 2012. If you know that a JavaScript method is dangerous, our main advice is to find a safe alternative. If you can’t do this for some reason, you can do context-sensitive output encoding in the browser before passing the data to an unsafe JavaScript method. OWASP’s guidance on how to do this correctly is covered in the DOM XSS Prevention Cheat Sheet. Note that this guideline applies to all types of client-side XSS, regardless of where the data actually comes from (DOM or server). DOM based XSS Prevention – OWASP Cheat Sheet Series
Consequences of XSS attacks
Expose the user’s session cookie, allowing attackers to hijack user sessions and control user accounts.
Other harm includes exfiltrating users’ files, installing Trojans, redirecting users to other websites, and modifying the way content is presented.
An XSS vulnerability that allows an attacker to modify a press release or news item could impact a company’s stock price or reduce consumer confidence.
An XSS vulnerability on a pharmaceutical website could allow an attacker to modify dosage information, leading to an overdose.
For more information on these types of attacks, see Content_Spoofing. https://owasp.org/www-community/attacks/Content_Spoofing
How to detect XSS attacks
The best way to find vulnerabilities is to perform a security review of your code and look for all possible
Where to insert the HTML document. There are many HTML tags that can deliver JavaScript documents, and there are tools such as Nessus, Nikto, and others that can help scan for these defects, but they may only find superficial problems. If a site is vulnerable in one area, there’s a good chance that there’s a problem somewhere else as well.
How to protect?
OWASP XSS Prevention Cheat Sheet Cross Site Scripting Prevention – OWASP Cheat Sheet Series describes the main defenses against XSS. Additionally, it is critical to turn off HTTP TRACE support on all web servers. Even when document.cookie is disabled or not supported on the client, an attacker can steal cookie data via Javascript. This attack is launched when a user posts a malicious script to a forum. When another user clicks on the link, an asynchronous HTTP tracing call is triggered, collecting user cookie information from the server and sending it to another malicious server. This server collects cookie information so that an attacker can launch a session hijacking attack. This attack can be easily mitigated by removing support for HTTP TRACE on all web servers. The OWASP ESAPI project has produced a set of reusable security components in several languages, including validation and escaping routines to prevent parameter tampering and injection of XSS attacks. Additionally, the OWASP WebGoat Project training application provides courses on cross-site scripting and data encoding.
XSS syntax
It is common to embed XSS scripts in tags, but other tags can also embed XSS scripts.
like
Other attributes such as onmouseover, onerror.
onmouseover
click me!
onerror
Via encoded URI format
Base64 encode our script and put it in the META tag
CONTENT=”0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg”>
Example
1. Get cookies
<SCRIPT type="text/javascript"> var adr = '../evil.php?cakemonster=' + escape(document.cookie); </SCRIPT>