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."

Comments

Re:I fail to see how is this related to XSS

[phantomcircuit]

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...

Use some library/package or something

[cerberusss]

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.

Not so sane or OFF in Firefox 2

[Alcoholic Synonymous]

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.

Set network.cookie.cookieBehavior to "1"

http://kb.mozillazine.org/Network.cookie.cookieBeh avior

Oh... and NoScript...

[Alcoholic Synonymous]

The NoScript addon has Yahoo as one of their exemptions to its anti-XSS protection by default.

Sanitizing user imput is the most important part

[Spliffster]

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).

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 /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).

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

Re:I fail to see how is this related to XSS

[morgan_greywolf]

Yes, since IE6, I believe.

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?