Show Menu
Cheatography
  1. Home >
  2. Cheat Sheets >

Introduction to XSS Cheat Sheet (DRAFT) by

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Summary

The second most well-known web app flaw next to SQLi.
OWASP: "Most prevalent flaw in web applic­ation today"
More difficult to prevent than SQLi, RFI/LFI and Command Injection.
Likely victim is the end user not the vulnerable app resulting in less incentive to address the flaws.

HTML Injection

Provide malici­ously crafted input that results in attack­er-­con­trolled HTML within the server's response.
The primary goal is arbitrary HTML rendering by the victim browser.
The lack of saniti­zation is the flaw but the victim is the rendering browser.

Script Injection

XSS often feels like manife­station of HTML injection with JavaScript able to be injected.
<sc­rip­t>a­ler­t("H­ell­o!")­</s­cri­pt>

Origin of Trust

Origin Server Same-O­rigin Policy (SOP)
Basic and critical security component of the web. THe goal is to make us feel safe.
SOP is only meant to prevent code from one site accessing content sent from another origin­-se­rver.
Requir­ements:
Port: Important when using tools to target internal apps that use nonsta­ndard ports
Scheme­/Pr­otocol: HTTP/HTTPS most common difference encountered
Host: The main source of variance and the focus of SOP restri­ctions
Same-O­rigin determ­ina­tions and SOP restri­ctions are governed by the browser.
A browser will allow an externally sourced script because it sees the origin­-server as requesting we fetch the externally sourced script.
Can circumvent space limita­tions by externally sourcing scripts. This is not bypassing SOP but presenting scripts as if they came from the origin server.
Goal isn't just to get code execution but to get the content as coming from a particular origin server.

Popups and Altern­atives

For initial testing and discovery of XSS simple popups work as POC. Not enough to demons­trate the risks of XSS.
Classic: alert(­"­hel­lo");
Classic look more style: confir­m("h­ell­o");
Altern­ative: prompt­("Pick a number from 1-10", "­5");

Classes of XSS

1. Reflected (non-p­ers­istent, type 2)
2. Stored (persi­stent, type 1)
3. DOM based (type 0) iis newer
Self-XSS involves scammers tricking victims into copying commands into the address bar that leads to adversary controlled JavaScript execution
Univer­sal-XSS is typically not a web app flaw but instea a method of injecting JavaScript by means of exploiting a separate tool, the most common targets being browser and associated plugins.
The goal is achieving JavaScript execution in the browser. The manner in which this is achieved differs by class.
  

Reflected XSS (Non-p­ers­istent)

Easiest to understand and simplest to discover
Most commonly used example of XSS.
Example:<sc­rip­t>a­ler­t("H­ell­o!")­;</­scr­ipt>
Input is dynami­cally added to the HTML without any encoding.
Payloads are immedi­ately delivered to the victim and will not persist for either the victim or other users.

URL Encoding (Percent Encoding)

Can be used for filter bypass but must be mindful of proper encoding
Burp Decoder will encode all characters even URLSafe charac­ters, which can prove useful.
ZAP will encode characters that the tool considers to be unsafe.
Firefox Web Console is located inside the developer tools and will encode a parameter with the function encode­URI­Com­pon­ent() or if passed an entire URL encode­URI().
Each technique produces a unique encoded output but all function the same.

Stored XSS (Persi­stent)

The other major type of XSS typically relevant to applic­ation assess­ments.
The advers­ary's input will persist across additional intera­ctions with the site.
More difficult to discover and not reliant on social engine­ering.
Common app functions with increased likelihood include blog comments, forum data, message functi­ona­lity, log mechan­isms, account profiles, support functi­onality.
Any aspect of the app that facili­tates commun­icating inform­ation to users or admins is important.

Out-of­-Band Stored XSS

Indirectly supplying input that results in JavaScript executing within a web app. Intera­ction s not always possible.
Apps with more obvious OOB Stored XSS potential include web-based email clients and security device consoles (IDS, SIEM, Firewalls)
Any app where OOB inform­ation we control has a high likelihood of being rendered.

DOM Based XSS (Type 0)

Exploit still results in JavaScript execution.
Primary victim is the client.
Methods of discovery and exploi­tation similar to Reflected XSS because it most likely involves a dynamic request, non-pe­rsi­stent response, and social engine­ering.
Distin­gui­shing feature is server does not deliver the attack to the client. Instead the client­-side of the applic­ation allows for malicious JavaScript execution.

Server versus Client XSS

There can be non-pe­rsi­stent and persistent version of tradit­ional and DOM based XSS.