Think you've protected your web applications from cross-site scripting (XSS) vulnerabilities? The odds are against you. Roughly 90 per cent of web applications have this problem, and it's getting worse as web applications and web services share more and more data. Many frameworks and libraries are encoding, decoding, and re- …
A hearty "thank you" to Jeff Williams, for a clear and concise overview of XSS. I trust that clarity of this kind spurs ingenuity In this case, it could well result in practical frameworks that reverse the predicated increase in XSS vulnerabilities.
Moreover, I hope the people at Mozilla are taking note. Like other open-source/widely-supported software projects, Mozilla needs to make sure their development roadmap addresses today's issues, not only the whim of corporate sponsors.
[ I am not implying anything untoward. Firefox is essentially a public tool. The weight of that relationship bears some obvious responsibilities toward users, above another company's product rollout. ]
Knock, Knock ...... although the Door is Wwwide ajar and Beckons Entry?
"XSS isn't going to go away anytime soon - in fact the problem's going to become worse thanks to AJAX, web services and Web 2.0. The key to containing the problem, though, is to act tactically and strategically whilst building web applications."
Some who are into XSS do not consider any code injection into other sysytems as being a problem. In fact, they would probably tell you IT acts as a tactical and strategic tool for them whilst building web applications.
And yes, I would most definitely agree that it isn't going to go away anytime soon but the only applications which will "suffer" as a result of XSS trials and betatests will be those applications which are discovered to be faulty and concealing embedded and embedding codes of their own, which would rather not be discovered because of their toxicity/self aggrandisement.
Not all XSS is bad. Some of it is very very Good even though it be decried as being bad because of its Ability to Crash Systems Easily. Such Systems are obviously badly Programmed and therefore Servering badly as any Good [AI Beta] System will always FailSafe and Repair ITself QuITe Automatically.
Thanks for the heads-up on the issue. A cogent article indeed highlighting a simple but impossible to stop opportunity which, when allied with the Zero day vulnerability, can be XXXXPloited mercilessly/mercifully to Good Effect by Skilled, Well Schooled Programs/Programmers/Virtual Machines.
And meThinks that only the surface has been scratched of that which such Coding XXXXPloits can achieve. And the most Virulent and Pervasive of them go Straight to the Core of Systems with no Prior Warning, should they be mooted and ignored. And in Plain Text, are they most easily transcribed and transferred across all and any Systems for a Concerted Tactical Advantage for Strategic Change.
I enjoyed this article, and I am passing it on to a number of students I know who do PHP development.
Also, congratualtions to amanfromMars for its best post ever. "Some who are into XSS do not consider any code injection into other sysytems as being a problem. In fact, they would probably tell you IT acts as a tactical and strategic tool for them whilst building web applications." Absolutely dead on! I know plenty of tools who work in IT. I take back anything bad I ever said about amanfromMars.
It is worth pointing out that XSS avoidance doesn't actually require that you validate you inputs - so long as when you echo it back out on to a web page you encode it properly so that its not interpretted by the browser.
Now, don't get me wrong as if you don't check your inputs before passing the data on you are exposing yourself to all kinds of potential injection problems. But then, white-listing your input character set isn't going to protect you from SQL injections if you accept apostrophes - which is commonly allowed in surnames. So, while there are some really simple checks that you should do, if you understand the security issues then you can not bother to check your inputs, encode your outputs and write database queries through prepared statements or stored procedures and avoid all the problems eluded to in this article. Question then, is what else do you need to be aware of... XSRF would be a good one to investigate... or maybe you should look for open source or commercial web site testing tools that will automate the task of scanning form parameters (including hidden ones) and URL parameters... etc... etc... etc...
The real issue for IT at the moment is that these security issues require developers understand them and code their applications defensively. Annoyingly its like the law... not knowing is no defence... Even worse is many people like to exasperate security issues rather than simply solving them (even if the solution is only short term while we wait for the hackers to adapt techniques or invent new ones)
Why should XSS be around for some time to come? If the web server understands that all executed and dynamic code must be encoded before being outputted (unless explicitly allowed) then this is nothing more than marking data as dirty and tracking it as it comes out the JSP / ASP.NET / PHP / whatever server side scripting engine.
There are plenty of free resources on the Internet and any developer that isn't already familiar with this stuff should learn it... fast.
- Does Apple's iOS 7 make you physically SICK? Try swallowing version 7.1
- Fee fie Firefox: Mozilla's lawyers probe Dell over browser install charge
- Pics Indestructible Death Stars blow up planets with glowing KILL RAY
- Video Snowden: You can't trust SPOOKS with your DATA
- Review Distro diaspora: Four flavours of Ubuntu unpacked