[shakna]

XSS tends to be the first step in a chain of exploits. There are examples of using it for account takeovers, but XSS being the first step, usually means it doesn't get called out directly. The particular chain sequence gets a name, and that is what gets put out in media responses.

[mmsc]

Yes, finding some PoC for account takeover or something that involves XSS is cool and whatnot, but I'm asking whether these theoretical chain of exploits have ever actually been documented as being exploited to a significant degree.

[kevindamm]

You have to look a little further back into mid-2000s to see larger impact XSS attacks, but each FAANG has had to recover from them. I'm on mobile right now but I'll look for some examples later.

What most companies realize early on is that you can't guarantee you'll prevent an XSS from slipping through. But, having a good template engine that sanitizes all strings automatically is good enough preventative measure, and putting all user-submitted content on a different subdomain or domain (like usercontent[dot]company[dot]com) with browser same-origin policy and perhaps CORS rules, will be enough to keep the impact contained. From there, just about everything else can be categorized as user error.

[thomas34298]

I'd say a strict Content Security Policy (at least script-src 'self' WITHOUT unsafe directives) is even more important to keep the impact contained, so you'd have to put your scripts into separate files - as opposed to using inline scripts. It obviously won't help against "HTML injection" in general, but will shield your users from malicious scripts as long as you make sure that an attacker can't just upload scripts on the permitted origin(s).

[thomas34298]

Here is an example: https://www.wordfence.com/blog/2020/05/nearly-a-million-wp-s...

That is what happens if you are the WP admin and think that you don't need to update your plugins because "it's just XSS, nothing major".