Cross-Site Scripting (XSS)

Notes

The travel code finally lost its asterisk today, which is worth celebrating, so here is a quick article.

XSS Principle

XSS refers to an attack in which an attacker takes advantage of insufficient filtering of user input by a website. The attacker injects HTML code that can be displayed on the page and affect other users, stealing user data, performing actions as the user, or harming visitors with malicious scripts. If malicious executable script is injected on the client side and the server does not process user input strictly enough, the browser executes the injected script directly.

Common Locations

Places where data is exchanged

• GET, POST, headers
• Feedback and browsing
• Rich-text editors
• Various tag insertion and customization points

Places where data is output

• User profiles
• Keywords, tags, and descriptions
• File uploads

XSS Types

Reflected XSS (Non-Persistent)

The most common case is a payload constructed in the value of a GET parameter in the URL. For example:

http://www.xx.com/company/search.html?key_pro="><script>confirm(ckcsec)</script>

Unlike stored XSS, reflected XSS submits content and reflects it directly back to the page without going through the database. The following code has reflected XSS because it directly outputs the value submitted through the get parameter:

echo $_GET\['get'\];

Attack flow:

Case

Fahuo100 CMS

<script>alert(1)</script>

http://123.57.94.143/

Stored XSS (Persistent)

Stored XSS is also called persistent XSS. "Stored" means the payload is saved somewhere. When a page has stored XSS and the injection succeeds, every visit to that page triggers the XSS. A typical example is a message board:

1. Insert a message => the content is stored in the database.
2. View the message => the content is retrieved from the database.
3. The content is displayed on the page.

If XSS exists here, the payload can be submitted through the message content and becomes effective when displayed on the page. That is a typical stored XSS.

Attack flow:

Case

DVWA range, XSS (Reflected)

DOM-Based XSS

DOM stands for Document Object Model. DOM allows programs and scripts to dynamically access and update document content, structure, and style. DOM XSS is a special type of reflected XSS based on the DOM document object model. DOM-based XSS does not need to interact with the server; it occurs during client-side data processing.

DOM XSS can also be considered a special reflected type, but it is usually treated as a separate category. The payload often looks like this:

http://xxx.com/xx/xxx.html#<img src=0 onerror='alert(0)'>

The underlying code may look like this:

<script>
var name = location.hash;
document.write(name);
</script>

By inserting an img tag into the page, a GET request is triggered. This is usually something like access-source logging. If the Referer value is not processed safely, DOM XSS can exist.

Case

jQuery-with-XSS

https://vulnerabledoma.in/jquery_htmlPrefilter_xss.html

The three major types are listed above. Some other types are briefly introduced below.

UXSS (Universal Cross-Site Scripting)

UXSS uses browser or browser-extension vulnerabilities to create XSS and execute code.

Practical examples for reference

MICROSOFT EDGE uXSS CVE-2021-34506

The Edge browser translation feature caused JavaScript statements to be invoked and executed.

https://www.bilibili.com/video/BV1fX4y1c7rX

Flash XSS: SWF Referencing JavaScript

XSS generated by Flash mainly comes from:

• getURL / navigateToURL redirects
• ExternalInterface.call invoking JavaScript functions

PDF XSS: Triggered by Direct Link After Upload

• Create a PDF and add a JavaScript action.
• Obtain a direct link through file upload.
• Trigger it by visiting the direct link.

UTF-7 XSS

UTF-7 XSS can be triggered in older versions of Internet Explorer in the following scenarios:

• The meta tag does not specify an encoding, and a specific IE version detects UTF-7 encoded content and automatically decodes it as UTF-7.
• The encoding is explicitly specified as UTF-7.

The difference between UTF-7 XSS and ordinary XSS is that the payload is UTF-7 encoded. Because of the two behaviors above, old IE versions automatically decode it, creating XSS.

MHTML XSS

MHTML XSS also exists only in older IE versions. MHTML stands for MIME HTML (Multipurpose Internet Mail Extension HTML), a standard that saves webpage content with multiple attachments, such as images and Flash animations, into a single archive. It is an HTTP-like protocol. In IE, when the URL protocol of an embedded resource is MHTML, IE calls the MHTML Protocol Handler and parses the resource as an MHTML file.

Content of x.html:

Content-Type:multipart/related;boundary="x"
--x
Content-Location:xss
Content-Transfer-Encoding:base64
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
--x--

Where:

PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg== BASE64 decoded: <script>alert(1)</script>

Triggered with a special access method:

mhtml:www.x.com/a.html!xss

CSS XSS

<style>
    body {width:expression(alert(1));: red;}
</style>

CSS XSS comes from IE versions before IE8 Beta2 supporting expression in CSS to define expressions and relationships between element attributes. The code above can trigger XSS.

VBScript XSS

VBScript XSS, like several of the types above, is also a Microsoft-related feature and can trigger XSS.

<input type ="button" onClick="VBScript:Document.Write 'ckcsec'

MsgBox 'xss'">

mXSS (Mutation XSS)

Reference: https://www.fooying.com/the-art-of-xss-1-introduction/#mxss

Common Payloads

https://github.com/payloadbox/xss-payload-list

Testing Tools

• XSStrike

• BruteXSS Terminal

• BruteXSS GUI

• XSS Scanner Online

• XSSer

• xsscrapy

Summary

Vulnerability principle: accept input data, output and display it, then let the browser parse and execute it.

Basic types: reflected (non-persistent), stored (persistent), and DOM-based.

Common tags: https://www.freebuf.com/articles/web/340080.html

Attack uses: blind XSS, cookie theft, credential theft, page hijacking, phishing, persistence, and more.

Discovery methods: code auditing, XRAY scanning, XSCAN, manual probing, and Burp fuzzing.

Fixes: character filtering, contextual encoding, http_only, CSP protection, WAF interception, and more.

Testing flow: look at where output appears, infer where input enters, then change the input code and observe execution. Tags and filtering determine the result.

Vulnerability discovery is not done overnight. Persistence matters.

Classic XSS POCs (Continuously Updated)

jQuery-with-XSS

https://github.com/mahp/jQuery-with-XSS

CVE-2021-41349

POST /autodiscover/autodiscover.json

%3Cscript%3Ealert%28document.domain%29%3B+a=%22%3C%2Fscript%3E&x=1