Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
@inaba yeah, but not for all types of XSS atacks...some of which could be mitigated by default...
-
@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... -
inaba46316y@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? -
Kaji22636yAren’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?
Related Rants
-
fabiomsnunes22Stupidest client ever: I once had a client that requested me a new website, all went well and get paid. After ...
-
Coffe2Code13~During app demo to our client~ - And when you click here the request will be submitted, the admin will be no...
-
watzon20This is what happens when you listen to clients
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!
rant
fuck this shit
stupid
xss