[killahpriest]

Whenever people teaching others about security mention XSS, I've always wondered does it really even happen in the real world? I'm sure everybody escapes their input.

Turns out there's a reason XSS is so often mentioned. Even Dropbox and Facebook fell prey to it (although in this case the input wasn't from the web, but rather from their desktop application/service partner).

[charliesome]

> I'm sure everybody escapes their input.

That's the fundamental mistake. Don't escape input, escape output. If you're interpolating values into queries, that's an output that you need to escape for. If you're sending data to a browser, that's another output that you need to escape for (with different escaping rules).

[aidos]

It wasn't so many years ago that xss wasn't on anyone's radar (just like sql injection years before that). Over the years I've worked on dozens of sites that were exploitable via XSS (many older ones that probably still are).

It's easy to get wrong - especially when you look through the list of different subtle ways you could mis-escape something [0].

The only thing protecting the majority of sites is that exploiting them just isn't desirable.

[0] https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She...

[reginaldo]

I recently found a pretty simple one on https://accounts.google.com/, which is arguably Google's most valued domain. I believe XSS is the most common vulnerability these days. One doesn't even have to be able to inject javascript per se. Only a CSS style is enough in many cases.

[TomAnthony]

The bounty for that page is ~$10k or such, no? Did you get anything?

[reginaldo]

Actually it is $3133.7 (eleet). I got it, of course. The security team at Google is, simply put, awesome.

[giulianob]

The problem I see is that if you aren't using a templating engine which automatically escapes things, people will make mistakes. Even then, there's times that you need to output raw HTML and perhaps end up forgetting to escape the part that was user input.

[lucian303]

Yes, even with just PHP templating, you still would need at least wrapper functions around things like

print htmlspecialchars($input, ENT_QUOTES, 'UTF-8');

Otherwise, yeah, someone will miss one instance and that's all it takes. One attack vector.

[giulianob]

well PHP doesn't really handle it for you so you do have to call the function yourself. If you look at something like Razor for ASP.NET MVC, everytime you output a var (i.e. <span>@Model.FirstName</span>) it will automatically escape it. If you do not want to escape, then you need to call Html.Raw instead. PHP defaults to not escaping while it really should to make XSS less likely.

[iends]

A few years ago, I found a simple one on the apple.com store. No bounty, but they said thanks in an email! :)

[lucian303]

Yes. And SQL injections are still #1 followed by code injection as #2 app vulnerabilities (I believe that's from last year but I wouldn't expect changes). XSS is up there. Why not? It's so easy and there is no excuse for any of this. None. Period.