XSS: Cross-Site Scripting

One of the most important families of modern security vulnerabilities is XSS which is this:

When Malicious User A can get code to execute in Innocent User B's browser using your app

The App Developer provides the canvas (vulnerability) on which your users hack each other.

Let's do a live demo:

Here is a firebase-driven chat app: /xss/insecure visit at your own risk. Say hi. The source code is below:

XSS Level 0: Now I'm going to send the message Hi <style>li{color:salmon}</style>.

Two questions:

Question 1: What's the worst that can happen?

Imagine Exploits I'm going to ask you to brainstorm with your neighbors, your job is to imagine an elaborate WORST CASE SCENARIO for what kind of damage can happen from this flavor of XSS exploit. After a few minutes of discussion drop your concepts in the class-chat and present the imaginative movie plots where XSS is used to do severe harm.

Question 2: How can we prevent this as developers?

Here is XSS prevention (perhaps the whole course?) in a nutshell:

All User Data is Evil and Must Be SANTITIZED

This solves the problem in a pretty hard-core way:

Here is that code running: /xss/secure

Observe the difference.

In vanilla Javascript this is the difference between: $el.innerHTML = and $el.innerText =

So now what?

Well unfortunately this was Level 0 of XSS. The reality is that your client will ask for functionality and most functionality requires having users do something.

It is easier to build a wall than a door

User Stories: Our client wants people to have a personalized Avatar image and to be able upload meme images and gifs and things into this chat app. How must you redesign the code to allow images but not arbitrary XSS?

The game of XSS over time is the cat and mouse of giving an inch and devising clever ways to take a mile.

Today's Flag

https://xssflag.web.app/

On this one it's hard enough, and important enough, that I want to maybe wax poetic for a second:

Stages of the exploit:

Is there complexity to getting your code execution? If so then what variations can we try? (Payload all the things)
Is the XSS blind? i.e. running on a page that you personally can't access? (In a ticket-system or feedback mechanism that the admin reads).
Your feedback loop: how are you going to fix your broken payloads
Exfiltration: how are you going to get the data from their computer to yours?

Don't Take My Word For It:

Let's look at the OWASP top ten: https://owasp.org/www-project-top-ten/

XSS flavors

Stored XSS is the above, where the vulnerability is in the database waiting for you
Reflected XSS is in an infected URL that gets rendered into the target's browser
The weird one is DOM-based XSS which is like reflected but if parts of the URL are written directly into the DOM before the scripting. (Minceraft is a bit like this)
A flavor that intersects all of the above is BLIND XSS, where your target will be navigating to pages you can't see.

Let's do a sort of twitch plays this: https://xss-game.appspot.com For each level take a few minutes trying to solve it on your own then use hints/online payload lists/googling to help you through. I want you to see the style of the XSS cat and mouse game.