Cross-site scripting (XSS) is a type of attack that can be carried out to compromise users of a website. The exploitation of a flaw enables attackers to inject client-side scripts into web pages viewed by users. Listed as one of the OWASP 10 vulnerabilities, XSS is the most common vulnerability submitted on the Detectify Crowdsource platform therefore a security risk our tool continually checks for

Cross-site scripting and how to fix it - Detectify Blog  - photo 1457305237443 44c3d5a30b89 e1458209886226 - What is Cross-site Scripting (XSS) and how can you fix it?

Cross-site : What can happen?

The attacker may:

  • gain access to users cookies, session IDs, passwords, private messages, etc
  • read and access the content of a page for any attacked user and therefore all the information displayed to the user
  • compromise the content shown to the user

A notable XSS attack was the Tweetdeck XSS worm published in 2014. It allowed the attacker to spread his malicious payload to all Tweetdeck users via Twitter, hence causing a mass compromise of Twitter accounts.

Example of Cross-site scripting (XSS)

To show how the vulnerability works, let’s look at an example. Say you have a search box on your site. If there is no result, the site should say “Could not find any pages when searching for [what the user searched for].”.

Doing this in PHP it might look something like this:

    // Code for performing the actual search
} else {
    echo "Could not find any pages when searching for ".$_GET['query'];

This would, in other words, output the user supplied data (the search query) straight into the HTML document. If the search query contains HTML, the user’s web browser will render it. Imagine an attacker sends a link like the following to a victim:<script>document.InnerHTML += "<img src='"+document.cookie+" />";</script>

This would make the victim search for:

 <script>document.InnerHTML += “<img src=‘”+document.cookie+“’/>”</script>

Since there is no validation of the data, the target browser will render:

Could not find any pages when searching for <script>document.InnerHTML += "<img src='"+document.cookie+"'/>"</script>

The injected HTML will be executed. The HTML contains a script tag which will evaluate JavaScript. The JavaScript will grab the user’s cookie and send it off bounds to a third party domain of the attackers control. The attacker will then be able to set their own cookie to the victim’s stolen one, hence gaining access the victim’s data. This is a common example of a privilege escalation attack by the means of cross-site scripting and session riding.

Cross-site scripting Remediation

The remediation of XSS vulnerabilities is heavily context-dependent and the patches vary. Here are some general tips (where UNTRUSTED is where user supplied data).




Convert to HTML entities (ie. & to &amp; etc).
See PHP htmlspecialchars()

HTML Attributes


<input value="">
<div attr="" />

Convert the untrusted user input to HTML entities to prevent the creation of other attributes and nver let any user data into the “id”, “class” or “name” parameters. Be very cautious when providing user data into DOM event handlers (e.g. onclick), at they are made to execute JavaScript.

Untrusted URL


<a href="">link</a>
<iframe src="" />

URL encode the user data, whitelist known URLs and run the user data through a proper URL library in your language. Take notice to the protocol specified and if you expect HTTP or HTTPS links, whitelist those. Prevent JavaScript from running by using a protocol handler.

GET parameter


<a href="">link</a>

URL encode the user data and prevent the use of ampersand as it may lead to parameter pollution issues.

CSS value


<div style="height:UNTRUSTED;"></div>

CSS hex encode the value.

Javascript variable


<script>var value="";</script>

Quote around variable and hex encode. Prevent line breaks.



element.innerHTML = UNTRUSTED

Sanitize using a library written in the language you use. Enforce the use of safer functions whenever applicable (e. g. innerText instead of innerHTML). Be very careful when determining what data is allowed to be printed. It’s better to have a whitelist of allowed characters than a blacklist.

For a more extensive list of tips, see OWASP XSS prevention tips. You can also learn more about XSS by heading over to our XSS resource page.

How Detectify can help

Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 1000 vulnerabilities, including Cross-site scripting (XSS). Sign up for a free trial and find out if you are vulnerable »


This article was updated on 7 August 2018.

Source link


Please enter your comment!
Please enter your name here