- Ep-5: What is DOM XSS
- Scope
- XSS Types
- Traditional Approaches To Input Validation
- Assignment 1: Exploiting DOM XSS (Scenario)
- Assignment 1: Exploiting DOM XSS
- Assignment 1: Exploiting DOM XSS (Hints)
- Assignment 1: Exploiting DOM XSS (Answer)
- Assignment 1: Exploiting DOM XSS (Answer Exploration)
- Assignment 1: Exploiting DOM XSS (Answer Exploration) CONT
- Persistent/Reflected XSS vs DOM XSS
- Persistent/Reflected XSS vs DOM XSS (CONT)
- Knowledge Dependency Tree
- What is DOM XSS (Cross-Site Scripting)?
- How is DOM XSS different from Reflected/Persistent XSS?
- Live Assignment: Exploit DOM XSS within OWASP’s Juice Shop!
- Why is DOM XSS so difficult to detect?
- Persistent
- Stored XSS
- Non-Persistent
- Reflected XSS
- DOM XSS
- Type 0 XSS
- 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
- Reject user input if it contains unexpected characters/strings
- 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”
- Ex: Check form fields for unexpected input before sending information
to the server
- Is this the only client-side validation that should occur?
- Of course not… :)
- Validate user input before sending to the server
- OWASP Juice Shop
- Intentionally vulnerable web app
- https://github.com/securingthestack/juice-shop
dom-xss-1
branch
docker run --rm -p 3000:3000 securingthestack/juice-shop:dom-xss-1
- Navigate browser to
http://localhost:3000
- Assignment Assumptions
- 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
- Result: Assume server-side validation of XSS is correctly occurring
- No form of client-side validation is occurring
- “Client-side validation is useless because we validate on the server”
- The browser has loaded all front-end code
- The application vigoriously monitors server logs for XSS and patches immediately
- Find an XSS flaw within
http://localhost:3000
without submitting a request to the server- Hints on next slide if you’re stuck
- 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
- If
- Look in
localhost:3000/dist/juice-shop.min.js
fortrustAsHtml
- Google Chrome Ex for Pretty Printing
- How can malicious input come into the client?
- Reflected XSS Module Ex.
<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
- 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 tong-bind-html
<h3 ng-show="searchQuery"> <span translate="TITLE_SEARCH_RESULTS"></span> <span ng-bind-html="searchQuery"></span> </h3>
- juice-shop.min.js
angular.module("juiceShop").config(["$sceProvider", function(e) { e.enabled(!1) }])
- Propigation
- Persistent/Reflected XSS
- XSS payload is embedded in server’s response to the client
- DOM XSS
- XSS payload stays within the browser
- Persistent/Reflected XSS
- 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
- Detectability
- Persistent/Reflected XSS
- Relatively easy to detect due to server logging
- DOM XSS
- No detectability
- Persistent/Reflected XSS
- Done :D