week07

Client Side Injection

• WWW
  • Everything is a document
  • Origin vs Site
  • HTML + JS
  • DOM
• XSS
  • Source + Sink
  • Goals
  • Exfiltration Methods
• CSRF

• WAF Bypass
  • Encoding
  • Other tricks
• Prevention
  • CORS
  • SOP
  • CSP

WWW

• World Wide Web
• Everything is a document
  • How those documents is client dependent
  • HTML, JS, VBScript

DOM

• Document Object Model
• An API for scripting languages to interact with web documents
• document.cookie, location.url, window.onload,
• Mozilla
• We use the DOM to access + exfiltrate info

HTML

• Static (on its own)
• Tags
  • Paired: <script>..</script>
  • Single: <img .. />
• Manipulating the tags in HTML is useful
• HTML encoding

JS

• Adds dynamic functionality
• Inline HTML using <script> or loaded externally
• Separate files
• Interacts with the DOM
  • document.write()
  • document.getElementById()
  • document.cookie
  • window.localstorage

l33t notes

• HTML is cAsE INSEnSItive
• <script>...</script>
• <img onerror="..." src="x">
• <svg/>
• document.write()
• fetch()
• hacktricks.xyz
• portswigger

Origin vs Site

What is an origin?

http://www.website.com:80

origin = scheme + host + port

What is a site?

http://www.website.com:80 > https://mobile.website.com:443 > ftp://f.website.com:21

site = private_domain + public_suffix

• Scheme doesn’t matter
• Port doesn’t matter
• Just the domain!

http://www.website.com:80

origin = scheme + host + port

site = private_domain + public_suffix site = domain

XSS

• User input is rendered as HTML
• Variants
  • Self
  • Reflected
  • Stored
  • DOM

Reflected XSS

The payload is part of a HTTP request, that is injected in the immediate HTTP response.

• GET request parameters
• Cookies
• POST request body

Stored XSS

The payload is stored serverside (e.g. file or database).

Typically more dangerous than reflected. Anyone who opens a page that returns content from that same database may be victim to a stored XSS attack.

• Twitter Self Retweeting
• Myspace ‘Samy’ Worm

DOM-based XSS

The client pieces together data which eventually becomes an exploit itself.

i.e. document.write(...)

• Validation - Blacklisting / whitelisting of input
• Sanitisation - Remove unsafe tags and attributes
• Encode - Escape data so it’s not a control character

Defense

Don’t use .innerHTML or .outerHTML

use .innerText or .textContent

Demo: DOM XSS

JS Frameworks

X-XSS-Protection header

Turn it off, it’s broken 🔥 🌊🚒

✅ X-XSS-Protection: 0

• Sometimes causes client-side errors on real code
• Has its own vulnerabilities

“Firefox never supported X-XSS-Protection and Chrome and Edge have announced they are dropping have dropped support for it."

Sandboxing

iframes, sandbox, seamless, etc…

Link: GitHub

CSRF

Cross site request forgery

Tricking a user into making requests they didn’t intend, sending data and loading attacker controlled documents

CSRF Tokens

Stop CSRF attempts by supplying the user with a single-use ’nonce’ value.

• When the page loads, a nonce is included
  • e.g. cookie, header, HTML form
• The nonce must be passed in the request
• Should be random and single use (per request OR per session, depending on system design)

Can’t forge a request if you don’t know the nonce before hand… sort of…

CSRF Token Attacks

• Better hope the server is handling CSRF tokens properly
• Single. Use. grr.
• Forge?
• Override?

CSRF vs XSS

• XSS - The JavaScript method
• CSRF - The HTML method

Generally XSS is performed in the background (since it’s a script exploit)

CSP

Content Security Policy

• Only allow content from specific sources
• Really useful (when used properly)
• Nonce is used
• Prevents
  • eval()
  • inline scripts
  • iframes

Implementation

• Policy defined in HTTP headers or HTML tags
  • HTTP is better
• Various settings

Beating CSP

• Exploiting trust
  • Hijack trusted source
  • Redirection
  • Inheritance
• Turn off the restriction
  • Insert own header
  • Split the response

CORS

Cross-Origin Resource Sharing

• Allows the server to specify to the client what parts of the SOP it needs to relax/ignore
• Set in HTTP headers
• Tells clients which sites (e.g. siteb.com) are allowed to read resources from itself (sitea.com)
• Browser uses preflight requests to check for CORS policies before making further requests
• Bad devs often set overly permissive CORS policies

Example

• We host the frontend on https://app.example.com/
• The frontend interacts with an API hosted at https://api.example.com/
• SOP will block requests to this by default
• We need to use CORS to allow this.

Preflight response headers (repsonse to an OPTIONS request to https://api.example.com/):

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization, X-Request-ID
Access-Control-Max-Age: 600
Vary: Origin

Response to actual request (e.g. PUT,POST)

Content-Type: application/json
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: X-Request-ID, X-RateLimit-Remaining
Vary: Origin