Cross-site scripting (XSS): reflected, stored and DOM
You find where data gets mixed into HTML as code, recognise the three XSS types in the lab app, close them with context-aware encoding and sanitising, and retest.
Level 201 · 17 lessons · 15 practice labs
Lessons
How XSS is born
- The root cause: data mixed into HTML as code
- The impact: session, action and content takeover
- Output contexts: HTML body, attribute, JavaScript and URL
- Short task: mark where user input is written to the page in the lab code
Recognising the types
- Recognising reflected XSS with Burp
- Stored XSS: from a comment to the admin panel
- DOM XSS: sources and sinks (location, innerHTML)
- Tracing DOM data flow with browser tools
- Short task: evidence each of the three XSS types in the lab app
Fixing
- Context-aware encoding: choosing the right escaping function
- Auto-escaping in template engines and the dangerous ways to turn it off
- Sanitising rich text: DOMPurify and allow-lists
- Safe DOM APIs: textContent versus innerHTML
- Short task: close the three XSS flaws in code
Detection and retest
- Seeing XSS attempts in access logs
- Writing regression tests for XSS
- Capstone: find, close and retest the XSS flaws in a blog app
Practice labs
- Find the XSS in this form and encode the output correctly: Prove with a harmless marker that the contact form's thank-you page reflects the name unencoded and fix it with HTML encoding.
- A parameter reflected in an error message: Prove the XSS on a page that shows an invalid page number verbatim in its error message and turn on the template's auto-escaping.
- A search term reflected inside an attribute: Prove the XSS where the search term is written into an input value attribute and apply encoding suited to the attribute context.
- A value reflected inside a JavaScript string: Prove the XSS in a parameter written into a string inside a script block and fix it by moving the value as JSON into a data attribute.
- Stored XSS in a blog comment: Show a harmless script stored in a comment runs for every visitor and encode the comment output.
- XSS that fires in the moderation panel: Find the stored XSS that looks safe in the visitor view but runs in the admin moderation panel and fix the panel template.
- Stored XSS in a display name: Find which pages run the stored XSS in a profile display name used across many pages and close every one.
- Auto-escaping switched off in a template: Find the stored XSS caused by auto-escaping switched off with a safe filter, remove the filter and sanitise rich text with an allow list.
- From location.hash to innerHTML: Prove the DOM XSS in code that reads the tab choice from location.hash and writes it to innerHTML and fix it with textContent.
- Tracing source to sink with browser tools: Trace with the browser debugger which functions a URL parameter passes through before it is written to the DOM and fix the unsafe sink.
- DOM XSS through jQuery html(): Prove the XSS in code that fills a notification box with html() and rewrite it with safe DOM APIs.
- DOMPurify settings in a rich-text preview: Find the element a misconfigured sanitiser lets through in a rich-text preview, narrow the allow list and retest.
- XSS attempts in the access log: Decode an encoded access log to find XSS attempts and list the targeted pages.
- A regression test for XSS: Write tests that check output encoding for three XSS flaws you closed and show the test breaks when a template change brings one back.
- An XSS clean-up in a blog app: Find, close and write tests for every XSS in the fictional Miraluna Blog and add a log query that catches attempts.
About this course
You find where data gets mixed into HTML as code, recognise the three XSS types in the lab app, close them with context-aware encoding and sanitising, and retest.
What you will learn
- How XSS is born
- Recognising the types
- Fixing
- Detection and retest
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run on your own Kali Linux desktop in the browser, with the tools ready in their windowed interfaces. Nothing to install; a computer screen is recommended.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.