Skip to content

Files

Latest commit

 

History

History

ep6-dom-xss

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 

DOM XSS

Ep-5: What is DOM XSS

Table Of Contents

Scope

  1. What is DOM XSS (Cross-Site Scripting)?
  2. How is DOM XSS different from Reflected/Persistent XSS?
  3. Live Assignment: Exploit DOM XSS within OWASP’s Juice Shop!
  4. Why is DOM XSS so difficult to detect?

XSS Types

  • Persistent
    • Stored XSS
  • Non-Persistent
    • Reflected XSS
    • DOM XSS
      • Type 0 XSS

Traditional Approaches To Input Validation

  • Building up to XSS Mitigations module
  • Server-side Validation
    • Reject user input if it contains unexpected characters/strings
      • Result: Response to browser doesn’t contain XSS
  • Client-side Validation
    • Validate user input before sending to the server
      • Ex: Check form fields for unexpected input before sending information to the server
        • Only deters the most novice “hackers”
    • Is this the only client-side validation that should occur?
      • Of course not… :)

Assignment 1: Exploiting DOM XSS (Scenario)

Assignment 1: Exploiting DOM XSS

  • Assignment Assumptions
    1. The application vigoriously monitors server logs for XSS and patches immediately
      • Result: Assume server-side validation of XSS is correctly occurring
        • No Reflected XSS in server response
    2. No form of client-side validation is occurring
      • “Client-side validation is useless because we validate on the server”
    3. The browser has loaded all front-end code
  • Find an XSS flaw within http://localhost:3000 without submitting a request to the server
    • Hints on next slide if you’re stuck

Assignment 1: Exploiting DOM XSS (Hints)

  • Where do many front-end frameworks store client-side state?
    • If x character is in the url, xFOO doesn’t invoke a request to the server
  • Look in localhost:3000/dist/juice-shop.min.js for trustAsHtml
    • Google Chrome Ex for Pretty Printing
  • How can malicious input come into the client?
    • Reflected XSS Module Ex.

Assignment 1: Exploiting DOM XSS (Answer)

  • <script>alert("Evil Code Is Running")</script> within Search field
  • Url inspection
    • q is after # so the browser won’t initiate a request
  • Imagine payload spreading via a malicious link

Assignment 1: Exploiting DOM XSS (Answer Exploration)

  • Strict Contextual Escaping (SCE)
    • Is a mode in which AngularJS constrains bindings to only render trusted values
  • Javascript Source
    $scope.searchQuery = $sce.trustAsHtml($location.search().q)
        
  • juice-shop.min.js
    r.searchQuery = e.trustAsHtml(n.search().q);
        
  • HTML
    • $sce.trustAsHtml will pass unsanitisized input to ng-bind-html
      <h3 ng-show="searchQuery">
        <span translate="TITLE_SEARCH_RESULTS"></span>
        <span ng-bind-html="searchQuery"></span>
      </h3>
              

Assignment 1: Exploiting DOM XSS (Answer Exploration) CONT

  • juice-shop.min.js
    angular.module("juiceShop").config(["$sceProvider", function(e) {
        e.enabled(!1)
    }])
        

Persistent/Reflected XSS vs DOM XSS

  • Propigation
    • Persistent/Reflected XSS
      • XSS payload is embedded in server’s response to the client
    • DOM XSS
      • XSS payload stays within the browser
  • Mitigations
    • Persistent/Reflected XSS
      • Can be mitigated by server-side/client-side input validation
      • Client-side validation
        • Native Angular functionality
        • Don’t want to rely on this
    • DOM XSS
      • Client-side validation

Persistent/Reflected XSS vs DOM XSS (CONT)

  • Detectability
    • Persistent/Reflected XSS
      • Relatively easy to detect due to server logging
    • DOM XSS
      • No detectability
  • Done :D

Additional Resources

Error Log

Knowledge Dependency Tree