XSS - TairinySimeonato/WebAuditing GitHub Wiki

Description

XSS attacks occur when:

  • Data enters a Web app through an untrusted source.
  • The data is sent to a user without being validated.

Stored, Reflected and DOM XSS

  • Stored attacks are those where the injected script is permanently stored on the target servers
  • Reflected attacks are those where the injected script is reflected off the web server
  • DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser

Reflected XSS

  1. User logs in an application.
  2. Attacker sends a malicious crafted URL to the user.
  3. User requests the attacker URL.
  4. Server responds with attacker JavaScript.
  5. Attacker's . JavaScript is executed in user's browser.
  6. User's browser sends session token to the attacker.
  7. Attacker hijacks the user session.

Stored XSS

  1. Attacker submits input with malicious JavaScript.
  2. User logs in an application.
  3. User sees attacker input.
  4. Server responds with attacker JavaScript.
  5. User's browser executes attacker JavaScript.
  6. User's browser sends session token to attacker.
  7. Attacker hijacks user session.

Difference between Stored and Reflected XSS

  • Stored is more dangerous than reflected
  • Reflected - attacker lure the victims to his crafted URL. Victims may not be logged in the application.
  • Stored- attacker just waits until user browses the page with his JavaScript. When XSS is triggered, victims are already logged in.

DOM XSS

  • DOM (Document Object Model) is a Javascript class that defines HTML elements as objects, supporting properties, methods and events.
  • DOM XSS happens when malicious input is inserted in the URL.
  • The difference between Reflected XSS and DOM XSS is that the payload for DOM XSS isn't shown in the source code.
  • DOM XSS payload is embedded client-side, while Reflected XSS is embedded server-side.
  • DOM XSS can only be found at runtime or by checking the webpage's DOM.
  • Attack payload is not necessarily returned in the server's response
  • Payload might be retained in the DOM and can be accessed by client-side JavaScript.
  1. User logs in
  2. Attacker sends a crafted URL to user
  3. User requests the attacker URL
  4. Server responds with a page containing hard-coded JavaScript
  5. Attacker URL is processed by JavaScript, triggering the XSS payload
  6. User's browser sends session token to attacker
  7. Attacker hijacks session

Sources

  • Sources are entry point for user input brought into DOM.

Common Sources

  • document.URL
  • document.referrer
  • document.documentURI
  • document.baseURI
  • location
  • location.href
  • location.search
  • location.hash
  • location.pathname
  • window.location

Sinks

  • The place where data depending from sources is used in a potentially malicious way. Location in which input can be executed in the DOM.

Common Sinks

  • eval
  • setTimeout
  • setInterval
  • document.write
  • document.writeIn
  • element.innerHTML
  • HTMLButton.value
  • Function
  • setImmediate
  • execScript
  • crypto.generateCRMFRequest
  • ScriptElement.src
  • ScriptElement.textContent
  • ScriptElement.innerText
  • anyTag.onEventName

XSS Impacts

  • take user account ownership
  • virtual defacement
  • inject trojan
  • induce user actions
  • exploit trust relationships
  • escalate the client side attack

Reflect and DOM XSS delivery mechanism

  • attacker sends a crafted URL via email, instant message, etc
  • via GET, an attacker can have a img tag on a 3rd party website targeting a vulnerable page
  • Attacker has his own website containing XSS payloads to a vulnerable application. Works if victim access vulnerable site and attacker website at the same time.

Stored XSS delivery mechanisms

  • 2 methods: out-of-band and in-band

In-band

  • happens when data is supplied to the page via its own main interface.
  • Common locations are:
    • personal info fields
    • questions/feedbacks for admins
    • names of files
    • messages, comments, questions fields
    • anything recorded in the logs and displayed in the browser
    • contents of file shared between users

Out-of-band

  • XSS payload is supplied to the app through another channel.

XSS Payloads without script tags

<body onload=alert('test1')>

<b onmouseover=alert('Wufff!')>click me!</b>

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

<IMG SRC=j&#X41vascript:alert('test2')>

<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

Characters such as ˂˃, ‹›, ≤≥, ＜＞, may get mapped to <> by a server and then not get encoded as &lt; &gt;

XSS via error page

http://testsite.test/file_which_not_exist Response: Not found: /file_which_not_exist Now we will try to force the error page to include our code: http://testsite.test/<script>alert("TEST");</script>

XSS via data

data:[mediatype][;base64],data

data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4="></object>

Php code review XSS

  • What's the best way to find? Start at the "source" and see how it's used.
  • $_GET["data"] - search "$_GET" sink - print source - user input

References

⚠️ **GitHub.com Fallback** ⚠️