Stay ahead of Web 2.0 worms
XSS marks the spot
Agentless Backup is Not a Myth
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-encoding with all kinds of schemes and sending data through new protocols. Ajax and other "rich" applications are complicating this situation.
XSS happens any time your application uses input from an HTTP request directly in HTML output. This covers everything in the HTTP request, including the query string, form fields, hidden fields, pull-down menus, check boxes, cookies, and headers. And, it doesn't matter if you immediately send the input back to the user who sent it - you get something called "Reflected XSS" - or store it for a while and send it later to someone else - that's "Stored XSS".
XSS is a fairly serious vulnerability. By sending just the right input, typically a few special characters like " and > and then some JavaScript, an attacker can get a script running in the context of your web page. That script can disclose your application's cookies, rewrite your HTML, perform a phishing attack, or steal data from your forms. Attackers can even install an "XSS proxy" inside the victim's browser, allowing them to control your users' browsers remotely.
Security problems like XSS are inevitable when you don't keep code and data apart - and HTML is the worst mashup of code and data of all time. There's no way good way to keep JavaScript code and HTML data separate from each other. To prevent SQL injection, you can use a parameterized query to keep the data and code separate. But there's nothing equivalent for HTML. Just about every HTML element allows JavaScript code in attributes and event handlers, even CSS:
Fortunately, there are steps application developers can take to protect applications:
Validate input: One way to keep code out of user input is "whitelist input validation." All you have to do is verify that each input matches a strict definition of what you expect, like a tight regular expression. Attempting to take a shortcut and apply a global filter for attacks is known as a "blacklist" approach and never works. Unfortunately, even the tightest input validation can't completely defeat XSS, as some input fields require the same characters that are significant in HTML - a you can see here:
?name=O'Connell&comment=I "like" your website; it's great!
COMMENTS
Security Problems
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.
Excellent article
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.
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."
Jeff,
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.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth
