BOOK THIS SPACE FOR AD
ARTICLE ADXSS has been there for so long now, probably younger than some of you and probably older than some of you xP
The term was coined in 1999 (or maybe 1998).
So in this post, I would talk about XSS being dead and maybe we still don’t want it to be gone… And in the end, I will leave you with some questions and possible solutions as well. This post is based on the talk given by Dr. Mario Heiderich in OWASP AppSec Europe 2018.
XSS has been there for so long now — more than 20 years and counting, and guess what — you will still see bug bounty and pentests reports having XSS listed in them! So where are we going? Are we so dumb that we haven’t been able to fix a seemingly simple vulnerability? Or do we love it so much that we don’t wanna fix it in the first place?
I am sure in the typical XSS tutorials that you see, you would find a slide detailing on how to prevent it right:
Input FilteringEscape things before processingEncode things before echoingTake care of the context which encoding and escapingBut even with all the knowledge we still miss the point! Why haven’t we been able to get rid of this seemingly simple issue? Any answers?
It’s all easy stuff right — most of the frameworks you may use nowadays come with a lot of these capabilities buit-in and with all this knowledge already, we still see instances of user input not being encoded or escaped. Why?
Because we’re lazy? Because we love popping off alerts? Or is there some other reason to it? Honestly even I am curious, with all the posts I write and the trainings I conduct, the no. 1 thing that I tell people to is never trust user input. Then why does it still happens?
Let’s take the 0th year after the inception of XSS as 0AX = 1999 A.D.
And XSS was born back then! The term XSS was coined by Microsoft after having a lot of alternatives — some very specific, some quite absurd and 1 fitting in place.
So Microsoft thought:
Should we call it:
- Unauthorized Site Scripting
- Unofficial Site Scripting
- URL Parameter Script Insertion
- Cross Site Scripting
- Synthesized Scripting
- Fraudulent Scripting
And Cross Site Scripting was chosen! And ever since it has been called XSS, which slips off the tongue quite nicely and is cool to speak about right ;)
But did you notice that it should be CSS not XSS but we still call it XSS haha!
Because its easy, flows like butter when we speak it xP
And so the baby was named!
Over the years, as things progressed and newer vectors were found by the researchers and attackers, we started seeing a lot of libraries claiming to eradicate XSS started to show up. And some of these were:
- HTML Purifier
- AntiSamy
- htmLawed
- Washtml
- Kses
- SafeHTML
- sanitize html
- HTMLSanitizer
- html-sanitizer
- HTML Sanitizer
- HTMLRuleSanitizer
- Google’s Caja
Some worked extremely well, some were quite bad with a lot of issues that the project maintainers left. Some that stuck around had to play the cat and mouse game of fixing the bypasses.
And with a lot of sanitizers as well this issue didn’t went away. Why?
Some people used the sanitizer incorrectly. Forgot to use it in some places. Used the outdated versions or worst — the sanitizer maintainer left the project while it was all buggy!
Great! And the story moved on and XSS grew bigger and bigger. So big that we started hearing the ideas of people creating XSS works — some small, some big, some lab worms and some worms that did a lot of damage! Samy Worm for instance which took down the MySpace network for 3 days followed by 3 years of probation!
While XSS was still growing, the security community also hit back with a bunch of security controls — some built into the browsers, some as external tools, libraries and plugins:
- Sandboxed iframes
- Subresource Integrity
- Suborigins
- Permission Delegation
- Trusted Types
- Referrer Policy
But we still had this issue :/ Why isn’t is still dead? Why did it thrive for soooo long! Why?!
So do we still need more standards? And behold! There came Content Restrictions, which was the precursor to the modern Content Security Policy that we know of today! The idea for CSP was conceptualized fairly early, and was such a great move!
Good so we have CSP too now, in our toolbelts, can we save ourselves from XSS now?
With the knowledge that we had the knowledge till that time — we could have stopped 99.9% of XSS vulnerabilities (which we can even do now!):
Content Transformation- Escape things before processing
- Encode things before echoingContent Sanitization
- Tell bad apart from good
- Leave only the goodContent Restrictions
- Define who and what can do what and where
- Hope that the trustee is trustable
And now since the trust also came into the picture, we already have a bigger problem!
But still if you see these points above, namely Content Transformation, Sanitization and Restrictions — these are good enough to get rid of 99.9% of XSS attacks!
So why do we still have this issue?
Are we still lacking some more tools? Some more headers needed? Some more inbuilt features into browsers?
In 2007 AD — year 8AX — we had ~1930 papers, patents and references to XSS research papers in Google Scholar!
So we have thousands of papers but still not a single bullet-proof way to fix XSS? Kidding? Or we don’t want to fix it?
In 2018 AD — nearly 20 years later — ~19,500 papers on XSS! What?! And still no good news? Do you need more? Hahaha…
And I just did a quick search today and see what I found:
Shocked? I am!! What are we producing so many papers for if can’t get the basic thing right?!
Even after 20+ years of XSS being there, we are still seeing bug bounty hunters and pentesters popping off alerts on websites including Microsoft, Facebook and Google. And if these companies can have these issues, I am sure a lot more have! No question about it.
Things that happen:
Content Transformation- People forget to escape and encode
- People escape and encode the wrong wayContent Sanitization
- Sanitizer gets bypassed
- Old Sanitizer library is used
- Wrong flags were usedContent Restrictions
- It’s too much work
- “Our ads won’t work anymore”
If you ask the developer why did XSS happened in the first place?
And you then get to listen a lot of “reasons” like:
Oh we just forgot to escape this one time — it won’t happen again for sure.Sorry, we’re using a legacy system. We’ll move to the safe one in the coming months. Please bear with us.We can’t afford to add security right now.Our custom code is way too faster than any framework.Our advertisers don’t like CSP.The dev who wrote this code is now working somewhere else.The point is that either have the encoding and escaping in the frameworks built-in or just get rid of it altogether, because surely we will miss things!
And all these excuses makes me wonder if we are all CEOs — Chief Excuse Officers!
We’re so good at delivering excuses or delegate guilt and responsibility to someone else but not a secure product?
The dev was dehydrated while writing the code.We can’t implement this because of that.The intern implemented this feature!Got so security budget from management.The project lead accepted the risk.So I think we should really start with ourselves right! And see what can we do to change things at our level — because if you see its all of us who are doing this blunder right. So why not start making a change from ourselves instead of shifting the excuse to someone else!
Let’s ask ourselves this question:
What do we really want?
Do we want to solve XSS?
Or do we want to pretend we do?
And just keep things as they are?
And keep popping alerts for money?
And if we wish to solve XSS then what do we need to do our job?
Do we need more tools? More standards? More headers? More complexity? Yet another CSP version?
Or maybe we should step back a bit and see what we are really missing on.
Is it the motivation to fix XSS in the first place?
And if that’s the case, how about using things like:
Punishment? If XSS bugs are found even after code reviews, you punish the offenders? so that they don’t make this mistake again?Gratification? Those who write secure code can be awarded developer of the month and be awarded and get some fame!Maybe we should “STOP THE BUG FETISH!” — Maybe we should have Fix Bounties besides Bug Bounties and give both sides a balance so that we are not neglecting those who fix the issues by getting their hands dirty, spending hours debugging and getting the patches out! And maybe we should stop glorifying the bug hunters that much — need a balance!I am in no way saying Bug Hunters are bad or evil but just saying that there needs to be a balance!
Maybe we can just start with being honest with ourselves and understand that if XSS was all gone, would we be more satisfied? Maybe you would have fewer bugs, fewer bounties but I am sure you don’t want to have a situation where even 15 years from now you would be popping the same alerts for money!
Do you? No right!
And if you don’t want to fix it, that’s perfectly fine, but I would say be prepared because sooner or later, people with the right mindset would jump in and address this issue, once and for all and then you would have to rethink your business model! So why not start today instead of waiting for the sudden change that pulls off the earth underneath you :)
I hope this rant was quite informational and lit a few lightbulbs in your brain, helped exercise some brain muscles and made you think more deeply!
If this post brings any change at all, that would be quite satisfactory for me :)
In case you enjoyed it, please share it among your friends in the infosec community!
Happy to get comments, feedback, and your viewpoints on this. You can connect with me on Twitter: @RuntimeSecurity.
Lastly, if you have been enjoying my work and would love to support me, consider checking my Patreon page or you can even Buy Me a Coffee :)
See ya!
Until next time my friend, keep learning and happy hacking.