XSS is another one of those buzzwords. You know what we’re talking about, the ones like “CSS, Web 2.0, DHTML, AJAX, Google,” and the rest. Except it’s dangerous. It’s dangerous because XSS is taken far out of proportions than it should be (just like the rest of the words on the list), but in XSS’ case, it can make perfect scripts look like Swiss cheese, even if they’re not.
XSS is short for “cross-site scripting” which it really isn’t - but that’s a whole ‘nother story. Basically, in XSS “vulnerabilities” scripts on a page are used to “steal” information from other open browser windows or tabs. XSS refers to scripts embedded in a page that when activated on an end-users system can (but not necessarily) result in a leak of sensitive information.
The problem isn’t so much in the attack itself as much as it is in the usage of the term. XSS is not a real security vulnerability in a product or script since it does not directly result in the loss of data integrity, but rather can be used as a tool in social engineering attacks and can never compromise the security of a server/host under any conditions nor that of an end-user on its own.
XSS is not the problem in and of its own. JavaScript is (largely) the cause, and XSS is but a result of the (many) inherint security holes in client-side scripting languages, specifically JavaScript due to it’s all-encompassing nature and it’s lax code (by nature) and not in the package itself. XSS itself is a tool like mentioned before, nothing more nothing less. But that fact has implications that render the entire foundation of XSS “insecurities” much less worthy of attention than they’re made out to be.
Sites with XSS vulnerabilities aren’t truly insecure. For the most part, they’re absoloutely no different than any other site - except that a user can manipulate the way content displays on an “insecure” page (usually by appending something to the URL or submitting a comment or other user-generated content on the page in question) and make it pose a possible risk to viewers. But it is of course of relevance when a major site presents even the smallest of vulnerabilities. However it is of the utmost importance to note that a page that has an “XSS vulnerablity” is no more dangerous to end users in practice than visiting a random result generated by a Google search - something that most users do all the time.
Sites that have been modified to pose such a risk can only be as dangerous as the scripting language used allows them to be - and as lethal as the browser being used lets them be. When a page has a potential XSS vulnerability, that means nothing. Such a page needs to be first manipulated in a way that embeds a script that can “steal” content from the end-users PC, then it must be sent to the user and by means of social engineering convince the user to open the URI. After that, the attacker has to rely on the user having the information he or she would like to “steal” available, and that the browser doesn’t block such an attack.
What matters in the end is that these products aren’t “defective” and not even truly insecure. They’ve been modified the way the language allows for them to be modified, no more no less.
Even that is inconsequential however, because today all modern browsers protect against XSS attacks in one form or the other. To test that, our testers headed off to OSVDB and searched for “XSS” “pops cookie” and “document.cookie,” which are the words most often associated with XSS vulnerabilities. Although the results varied from one browser to the other and from one build to the next, on average 60% - 70% of the XSS vulnerablities that were present and “functional” in the “last generation” of browsers (Firefox < = 1.0, Opera 8, Internet Explorer 6) didn't work in the "new generation" of browsers (Firefox 2.0-3.0 builds, Opera 9, Internet Explorer 7).
In the end, XSS as a vulnerability rating is abused and thrown around without consequence. It isn’t something new, it isn’t something special, it isn’t (necessarily) a sign of bad code, and it most certainly isn’t an excuse to rip an otherwise excellent product to shreds over security issues that don’t exist. XSS is a security hole and possible cause-of-headache, but beyond that, it isn’t worthy of the attention it gets and pales drastically when compared to the far more dangerous and more worthy security vulnerabilities that plague the web today.
[followup on this article's purpose and impact]
Guess what?
I just found 5 XSS security flaws on
AOL
CITIBANK
WELLS FARGO
IRS
MIT
all described, ready to exploit.
And guess what? Nobody gives a sh|t.
Then you haven’t submitted it to the right places or brought the correct attention to it Kay.
NeoSmart has a security bulletin team, you can forward all vulnerabilities to security@neosmart.net and a team member will get back to you ASAP - they’ll get published and you’ll get the credit if you’re interested..
Are you insane? Lets just say I hope NeoSmart doesn’t implement the next PayPal.
Do you propose having “if the users reads Digg or any other website while logged into our application, he has implicitly agreed to have his account stolen and NeoSmart shall not be held accountable” in the EULA? Just wondering.
XSS isn’t a vulnerability in JavaScript. In almost every situation I find it’s caused by insufficient sanity checking in server-side scripting languages.
I can’t say I agree that XSS is overhyped. I think it’s underhyped. I work with banks and credit unions and find XSS “issues” on their online banking logins constantly. Most of my clients have never heard of XSS and worse, they can barely understand it. When we run our phishing tests we use the XSS “issues” and always nab some valid credentials. So it doesn’t matter whether the server’s compromised if the business falls apart from bad PR because adequate measures weren’t taken to protect customers.
But for the sake of argument I’ll say that XSS isn’t a vulnerability, and it’s caused by insufficient sanity checking. The same cause of XSS may allow for a SQL Injection instead if the scenario is just right. So then would you say that SQL injection that can be used to extract a prolending database is also not a flaw?
XSS vulnerabilities are nothing but a joke. Nobody cares. Everyday vulnerability lists are spammed featuring awesome exploiters releasing XSS exploits for software that nobody cares about. The problem is nothing more than a nuisance.
Ahh I see we have a Microsoft Product Manager posing as a security consultant.
I bet even this site has XSS protection …
Click here to find out
Fair point *if* all websites are being accessed with the same level of trust.
But trust varies from site to site, both explicitly through technologies such as zones, and implicitly through user behaviour varying between sites.
Eg 1, if a user accesses a corporate intranet site, or lists a particular website in their trusted zone then that XSS vulnerabilities in that site can be used to gain elevated privs and cause some serious damage beyond what vanilla-plain websites can do.
Eg 2, I’m probably not going to enter my bank login details into a dialog that popped up from some-random-site.com, but most people would if it appeared while accessing my-xyz-bank.com.
Looky here!
http://neosmart.net/blog/index.php?s=Welcome to the Alan Alda fanclub. Please enter your password.
“Social engeneering attack”. Are you saying that the JS worm which propagated through yahoo’s system was a social engeneering attack? It was a clear technological failure!
If a site or rather a query string needs to be manipulated to achieve an SQL injection then is this not vulnerability?
Like one of the previous posts – 99% of time XSS happens due to programmer error and poor validation routines. This in it self seems to be a definition of a vulnerability of a sort – isn’t it?
Assume for a second that there is nothing you can do to exploit software “Z” (Z is just a cool letter and I like it) directly. Assume it’s a mail server. Your IP is blocked, it is locked down and secured, etc. However you know that if you relay a specially formatted message through some obscure path it will get through. I was under the impression that XSS is very simular – in fact I gave a presentation on it once. You create an obscure query string, relay it – say post it on a forum under false pretences and have a brew while you phish.
Yes, it does imply that there is a very big social engineering factor at work here, this can be considered as a trigger. However the actual exploit is performed by your query string exploiting the lack of proper input sanity checks.
Hence, the definition of an exploit.
Eh? So one site I use that has an XSS vulnerability allowed me to insert javascript into my profile and when the admin viewed it, the XSS submitted his (cookie-stored) password to me. From that I could alter any content on the site. I guess that’s not a vulnerability.
This article is amazing.
> XSS is not a real security vulnerability in a product or script since it does not directly result in the loss of data integrity, but rather can be used as a tool in social engineering attacks and can never compromise the security of a server/host under any conditions nor that of an end-user on its own.
Mail worms and myspace worms have made news recently.
Both are purely driven by XSS (and by users being “social engineered” into visiting sites they normally visit several times a day.)
Both type of worms can also result in account compromise and in loss/compromise of data stored under each of those accounts.
> Sites with XSS “vulnerabilities” aren’t insecure. They’re absoloutely no different than any other site - except (…) [they] pose a possible risk to viewers.
By the same logic, programs with buffer “overflows” aren’t insecure. They’re absolutely no different than any other programs, except they pose a possible risk to systems.
Which part of this makes sense to you?
> 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.
And of course, buffer overflows just are, and so long as C remains the buggy pointer-ridden language it is, buffer overflows will be, and that’s all there is to it. Right?
Wrong, of course.
No self-respecting security guru would dare to go on the record saying that.
Both C and JavaScript are good languages for their own purposes.
Both are misused by programmers who don’t grasp the implications of their shody coding.
It is very possible to write safe web applications, just like it is very possible to write a safe program in C.
Overall, your blog entry invites to unjustified complacency toward web developers, at a time where more users depend on web applications to get things done.
It is fallacious and unhelpful.
If you persist, please consider removing that “guru” thing in your blog title. “explorer” or “pundit” would be more fitting substitutes.
XSS can inject malicious content into trusted sites, as recently happened with paypal [1]. XSS can steal private data. Random google links can’t.
[1] http://it.slashdot.org/it/06/06/16/143208.shtml
When you wrote this, were you aware that an XSS vulnerability on a site that lets people log in with cookies (virtually every forum on the web for example) means an attacker can steal people’s accounts? If not, I suggest you retract the article and post a follow-up. If you were, I’d love to see justification of why that isn’t a Big Problem.
Hey, don’t go bashing Microsoft Product Managers. Microsoft considers XSS bugs legitimate vulnerabilities and offers guidance and technologies to mitigate the impact of XSS.
Hello Slashdotters..
Please don’t take this article out of context. NeoSmart Technology isn’t in any way, shape, or form implying that XSS security issues shouldn’t be bugged or secured. To the contrary, like any other security vulnerability, they should and must be dealt with promptly to minimize impact on all parties involved and to keep the symbiotic trust relationship between the website/company and the members.
However, the entire point of this article has been made clear and obvious by the effect it has had on the online community, considering that XSS vulnerabilities have “existed” ever since Netscape introduced JavaScript into its browser in the early 90s, yet it was not brought to the media attention until just the last year or so.
We’re not saying they’re not bugs, all what we’re saying is that they’re being given too much attention - far more than they actually deserve for a variety of reasons.
Either way, XSS vulnerabilities are by far the most “popular” and easiest to find - and as many of you pointed out, easiest to fix as well. As such we feel they aren’t worthy of the media attention if in but five to ten minutes of work the vulnerability can be satisfactorily taken care of with minimal harm done.
XSS vulnerabilities are real, but it’s one thing to be real and another to be a highly convoluted and controversial topic taken far out of proportion and twisted into something it isn’t. At NeoSmart we will continue to find, take, process, and warn for XSS vulnerabilities in products, sites, and services, but it’s just a question of how highly it is rated and how much attention is given to it by the media and technogeek communities at large.
In all honesty, we published this article expecting controversy (but not this much, thank you Slashdot!), after all we are trying to de-priotorize something that has become quite big recently, but it is extremely important in our opinion to head this off before XSS becomes “more important” in the eyes of the people than the real vulnerabilities that take time to find and exploit or fix, and can have truly disasterous results for all parties involved.
Your site is XSS. [IMG SRC=. ONERROR=alert(document.cookie) /] into the search field
R0!g%t 0n d00dz! XSS 1-/_ Nu%%1n bUT Kr4p.
I 4M 31337 S3KuR1t3 GuH 700, 4ND ! 4m 70T4llIE 4Gr331ng!!
> As such we feel they aren’t worthy of the media attention
> if in but five to ten minutes of work the vulnerability can
> be satisfactorily taken care of with minimal harm done.
This is a remarkably stupid way to analyze the risk posed by a vulnerability.
If you want to figure out the impact of an XSS vulnerability, it doesn’t matter whether the vulnerability is easy or hard to fix. What matters is the content of the web site with the vulnerability. If the web site hosts recipes for chicken marsala, don’t sweat it. If the web site hosts something more sensitive, your e-mail or your financial information, you need to be concerned.
Erm XSS vulnerabilities need no Javascript.
Merely allow an img tag with a src point to:
http://dodgybloke.com/fake.gif?PleaseGiveMeYourCookies
Browsers will send the cookies are sent as part of the request. No Javascript required.
Obviously Javascript allows you to do more funky attacks than this, but to lay the blame on a language you seem to have a problem with seems unfair. VBScript was an amaturish attempt at a proper programming language. Besides, every JS attack could be recoded in VBScript.
Your argument against scripts on the host is one to get over. Gmail, et al has showed the world Scripts = nice apps, no scripts = poor, slow apps. There is simply *no* way to remove the long latencies required by unscripted webpages. Ye canne’ change the laws of physics. Take this from a developer.
However.
W3C/webtoolkits could help out here by giving developers better tools in their script languages to avoid such pitfalls.
One would be a “SafeParse” function, that understood all the known XSS attacks, and strips them out - preferably with a mechanism to log the potential breach. Wikipedia’s sw has a homegrown one that is robust, and developed thru mass exposure to the internet. Any small outfit developing software is never going to be so lucky.
I don’t think that example in your post would work: the way cookies work requires that the domain be the same to retrieve the cookie of interest, so you’d be getting a cookie from dodgybloke.com, but that fake script shouldn’t be there in the first place… unless I’m misunderstanding your point.
I have no doubt that JS has reformed the web as we know it, after all, it does form the backbone of AJAX (although that’s not a necessity, but it does anyway). But I believe that JS is too loose, and has a lot to risk. JS needn’t be as “powerful” or lax as it is, and that’s where the problem stems from. Obviously client-side scripting is very important for two-way communication with a site, but JS is quite far from being the “ideal solution” for such a scenario - but it’s a step.
Actually we’re working on an anti-XSS implementation here, it’s much more simple than that - but it’ll only work on JS implementations of XSS, and not server-side functions that do stupid things (like the example you provided where the server itself has an open function to give up the cookie) - but we think it’ll help.
alert(”XSS”)
I have been a web application penetration tester for 4 years. I’m intimately familiar with XSS and the situations under which it can and cannot be exploited.
The author would be well advised to research the differences between stored and reflective cross-site scripting, best practices for data validation, and related vulnerabilities such as cross site request forgery.
I see you are using WordPress. There was a cross site scripting vulnerability in a prior WordPress version which would allow a regular user to gain admin access when their comment was read by the blog administrator. I was able to verify it on my own blog.
It’s just important to keep in mind that there are in fact many situations in which XSS vulns are practically exploitable. Also, be aware that stealing another user’s session cookies is not the only “payload” for this vulnerability. When you can execute arbitrary JavaScript code, you can make any call to the application that the user would be able to make (one flavor of cross site request forgery or XSRF), or you could re-write arbitrary content on the page, such as changing the value of an HTML form’s ACTION parameter to redirect the login credentials to a malicious site. These are just two of the ways to circumvent “HTTPOnly” cookies.
I do respect the article author bringing attention to the large amount of smoke and mirros discussions around XSS. There have been a number of XSS announcements which, although sometimes technically accurate, couldn’t be exploited in any meaningful way.
I also read the earth is flat
AAARGHHH… commenting system destroyed the link
here’s shortened link http://tinyurl.com/qux2n
Pointed out by fellow commenter above. Leads to simplest COOKIE THEFT on your own website…
Please… get back to XSS topic when you learn how to protect your own blog…
2 quick points in response to your comment adressed to slashdotters:
- XSS vulnerabilities have been used for real-world data and accounts compromise for almost 10 years. In the early days, it was essentially like stealing candy from a baby since barely anyone was aware of the risks. The situation is slowly improving, thanks in part to increased focus on the issue.
- If your entry is about over-exposure of XSS vulnerabilities, maybe you should mention it explicitely at least once in the main text. As it stands, your entry reads very differently from what you meant it to be.
I’m sure you’re aware of this, but Word Press is at version 2.03 now, and running an alpha system that has since been updated, while talking about vulnerabilities, is well, I hope not ironically prophetic for you.
By the way, cool Subscribe to commens checkbox, I’ll have to look into that for my site.
@Saskboy: as a matter of fact I’m on the 2.1 alpha, not the 2.0.1 alpha as you might have mistaken it for… just for the record, 2.1 alpha (svn trunk) security features have been backported to 2.0.3 (some of which concerned XSS vulnerabilities).
Oh, and to whoever had the “cute” idea of posting with my email address on the blog: you’re IP address has been blacklisted, but it doesn’t really matter since it was kind of obvious… and that’s not an XSS vulnerability as you “pointed out” in the email, it’s called social engineering, and a pitiful attempt at that too…
When making controversial proclamations to a large audience, it’s usually good to use a spell checker and proofread for grammatical errors.
Thanks for noting that Guru, I missed it.
Where can I find info on making a Subscribe check box if you have a moment to help?
–
Mark, sometimes you don’t know how big the audience will be until it’s too late.
Hello Saskboy…
Ours is a heavily modified version of Mark’s excellent Subscribe to Comments plugin.
We do our best to check for content, but we’re coders, not writers at heart, and the occasional grammer mistake eludes us - if you find anything, just let us know.. and that’s true, we really didn’t expect this much traffic, the webserver is actually buckling at the knees…
The article has been slightly tweaked to reflect the original intent of the post - the fact that XSS is exaggerated has been made more explicitly the point of the article, rather than XSS itself being not worthy of attention (which isn’t true).
Xss is very dangerous and totally fucking underhyped . Stolen cookies gives access to a logged in user. Give the admin the link and you’ll have access to the site if he has some sort of admin webinterface.
You’re using wordpress, repeat you’re using wordpress! How can you talk like this about XSS. I’m no security expert but I’m smart enough to know that you are smoking from the wrong end of the pipe.
Hey Harky.
That’s true, WP used to have quite a few XSS vulnerabilities, and still does (as demonstrated above).
But that’s the missing the point of the article. XSS exists and it can be dangerous. But the extent of danger is exaggerated. Here we are at NST running WP - but we’re still up and running even with a few minor XSS holes.
Well picture this guys and gals. What if someone injected persistent XSS onto SUN’s webpage, that redirected all of the users to Microsoft.com ? Imagine the amount of money SUN would loose on such an attack. You wouldnt like to own stock at SUN then, would you?
[quote comment="3881"]Well picture this guys and gals. What if someone injected persistent XSS onto SUN’s webpage, that redirected all of the users to Microsoft.com ? Imagine the amount of money SUN would loose on such an attack. You wouldnt like to own stock at SUN then, would you?[/quote]
And how exactly is this fatal???
Especially as XSS normally relies on secrecy and subversion - this kind of thing would be fixed in 6 minutes tops.
QED..