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."
You are in fact wrong. The cookie is sent through a form which is not affected by whether third party cookies are enabled or disabled. It should be noted that this flaw has already been fixed...
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?
Yes, since IE6, I believe.
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.
However, you should also be aware of the related XSRF (cross-site request forgery) attack, which can actually be done from a different site. For example, someone on your site says "Hey, go to myevilsite.com", and then when you view the page it uses Javascript to auto-submit a form pointed at your site. If that form happens to be "delete account" and you don't have any protection (such as a generated form ID that only legit forms from your site would have, or requiring a password), there could be trouble.
You're reading his code wrong, and third-party cookies are not required.
It's not what I would call "XSS" (those, I thought, had to do with code on one frame or tab accessing objects on another, and are therefore browser problems, not site problems); it's a JavaScript injection vulnerability. The link generated by the Ruby script, allegedly, inserts JavaScript code into a Yahoo page. This code is then executed with the same permissions as Yahoo code, and what it does is read your Yahoo cookies and submit them to some other site as request arguments.
The Perl code then parses the submitted data into cookies and pretends to be Firefox accessing Yahoo with your cookies.
session is automaticly aborted if HTTP_REFERRER is something else than a website on my server, or the CGI-script itself. Not really a strong way of countering such attempts, but combined with alot of other smaller things that i've implemented, it has proven useful.
this is probably the most boring sig in the world
As I understand XSS, it is any vulnerability that lets one inject code, usually javascript, into output from one site, causing data to be sent to another site. In my experience, it is usually caused by a site not filtering input correctly rather than a problem with a browser.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
For those who are not in the know, the problem with that particular solution attempt is that a vast majority of dialup users (AOL-ers, for example) sit behind a dynamic pool of web proxies that can have their IP address reassigned at anytime during the same dialup connection, and therefore during the same browsing session.
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
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.
Um, no. Neither IE6 nor Firefox 2 block 3rd-party cookies by default. In IE6, one can turn off 3rd party cookies with Tools -> Internet Options -> Privacy Tab -> Advanced. Check override automatic cookie handling, and then under Third Party choose Block or Prompt.
In FF 2.0, you need to do an about:config and set network.cookie.cookieBehavior to 1.
Any questions?
My blog
Whether it was disclosed to Yahoo directly or not, it has already been fixed (at least when I tested it in Firefox). I don't know about most of the Yahoo team, but Rasmus (the same one that invented PHP) pays very close attention to site security, and Yahoo, Google, and many others watch the boards where these vulnerabilities are revealed and fix the problems, often within hours, whether its disclosed or not.
Clones are people two.
Two things wrong with that argument:
We all know what to do, but we don't know how to get re-elected once we have done it
file://c:/www/includes/objFilter.inc