XSS mitigation is a pain in the ass.

After all this time, with all the brilliant developers around the world, why haven't we found a sane way to mitigate this shit by default?

Shit!

Most templating engines do tho

@inaba yeah, but not for all types of XSS atacks...some of which could be mitigated by default...

@balaianu which ones are you referring to?

@inaba there are some edge cases for url based injections in this application when generating languange change links.

The template language was not able to perform cleanup for that specific case and it took a lot of time to find the culprit...

@balaianu which ones are you referring to? (for both paragraphs)

And when you say URL based injections, do you then mean actual URL injections, or injections via GET parameters?

Aren’t there server-level fixes for this? I seem to recall several criteria for PCI compliance citing XSS concerns as their rationale...

@Kaji There are but in general it's hard and for end to end encrypted services it's even harder :/

@inaba Imagine getting a 200+ pages security test report, that basically lists more than half of the accessible URLs for the app and marks half of that a vulnerable to XSS attacks.

Yes it gives request headers data and response headers, but no data on what part of the page the vulnerability manifests in.

Add to that that most of these could be false positives, as we have already implemented the XSS prevention stuff for basically the whole app.

Also consider that when trying to reproduce the attack based on the report data you find nothing wrong, but since this is the third report mentioning this pages as vulnerable, you start doubting yourself.

What do you do?

In the end I asked for the live db dump and I find it.

The language change link generator uses db records for the alternative language URLs based on custom slug data. If it does not find any, it switches to GET param based URLs with the current URL and the lang to switch to.

On the testing version we had a pretty close version of the bd, but in prod some records were missing for page slugs.

So the link generator was returning an edge case version of this link, that was not filtered for XSS, and the template language apparently wasn't configured to filter this correctly.

No-one knew, because we would always get the correctly filtered, slug based links...

So the attacks went through in those cases.

It's fixed now, but man is it a pain in the ass debugging this shit!

Oh, and did I mention that only some of the attack requests were manifesting the problem?