Jibbering Musings

There’s been a big increase in making all your website projects beta in public, however most companies seem to have decided this means they can avoid actually testing their product before they release it. It wouldn’t matter much if was Joe’s random web application, but it’s not these beta products share the same domains as existing heavily used sites. This means domains are trusted by users, but people are expecting something different, this means that both compromised site phishing attacks like I described when I demonstrated the Google flaw last year, and attacks on user data stored on the same domain become very easy for an attacker.

I’m not a security consultant, I’ve no idea how to hack sites, I don’t go looking, but it’s trivial to find cross-site scripting (XSS) flaws in these beta’s, it’s almost too difficult to miss them, which is why I believe the public betas are getting so little testing that there are bound to me more.

Yahoo Maps Beta XSS flaw

Yahoo Maps beta for example contained an obvious flaw, viewing source showed

var lc_id = new String(Math.floor(Math.random() * 100000));
var v = new Vars(getHash(window)+'&'+getSearch(window));
var q = v.toString();
document.writeln('<iframe id="_bottom" name="_bottom" src="history.php?' + q + '" …

Which is pretty suggestive that the contents of the query string are being written into the page, looking at the rest of the code, you’ll see this is indeed true, the Vars() object just parses name value pairs which are then re-serialised back in Vars.prototype.toString() (see the original flawed code at http://jibbering.com/2005/11/yahoo-xss-original.txt) This means that visiting the url and adding a hash containing #”onload=’alert(1)’ would write in the onload event to the iframe, and the script would then be executed in the context of the page, a classic XSS attack.

Yahoo fixed this about 6 hours after I sent the email to their security address, no actual acknowledgement from yahoo of the report though, not even an automated reply from the security address. The ease with which it was fixed shows just how trivial the flaw was - all you need to do is ensure the query string doesn’t contain ” characters so the browser wholly considers the query string to part of the src attribute of the IFRAME. It’s something that in traditional development would have been picked up early, hopefully by the developer being aware of XSS attacks, or by the tester when they first looked at it.

I’m sure this isn’t just a Yahoo failure, indeed they should be applauded at the speed at which they fixed the flaw, however I’m also positive that these public betas are risking our data, the competition amoung the big portals who have so much of our data is forcing them to prematurely release products that have simply not been tested. Even if the commercial pressure is that strong they can’t stop, then they should start doing a few things to protect our data.

• Have the betas on seperate domains - not just seperate subdomains, no more maps.yahoo.com, or mail.google.com, but yahoobetamaps.com so there are proper cross domain walls between the beta site, and the valuable data.
• As I said before “stop releasing products, get all your developers into a room, get some good developers who understand Security to explain it to everyone. Then review all your code and sites, get some tests written, get defensive and sort your security out now, before exploits start actually getting used.” That was about Google, but it clearly applies to lots of other teams.
• Provide clear communication lines for people to report security flaws, and communicate with those who report them. I had to search for some time for a security email address for yahoo, it turns out security@yahoo-inc.com is the address, hardly obvious.

As traditional phishing becomes less successful as with the netcraft anti-phishing toolbar, or IE7’s Anti-Phishing filter, I’m sure the XSS phishing flaw will become more prevalent, as if the domain really is the domain of the site you think it is neither of these will provide any safety at all, in fact that make users feel even more confident they’re okay giving their data to the site.

If you have data on a domain that runs public beta’s, and you want to keep that data safe, never use the public beta, and certainly never follow a link to it from anywhere, type the URL into your browser bar yourself.