Jibbering Musings

The last few entries I’ve called developers incompetent for their security flaws, in the comments, some people have thought this unfair of me. They rightly point out that security is not easy, so it wasn’t reasonable to call people who fail incompetent, I stand by my description though. Security is hard, but this type of security problem certainly isn’t, in fact it’s not just a security problem, it’s also a “the site doesn’t work” problem.

The fundamental cause of these problems is content being written into the page unencoded, so the character < is considered the start of an HTML element, rather than part of the content. Or if the content is being written into an attribute then the character " or ' are considered to be the end of the attribute. (or even a simple space if you don’t bother quoting your attributes) This lack of encoding isn’t just a security flaw though, the site simply won’t work properly, as any test data that includes the characters won’t appear correctly on the page, this is the main reason why I blame incompetence on the testers and developers, or simple laziness, and not bothering to test at all.

Steps a developer can take

Hare are 3 simple things I use as a developer to mitigate the risk.

• Have < " in your toy test data, easy of course in your text input boxes, but also do it in your select values and radio values, that way you never need to actually test by directly entering a risky querystring, you can leave that to the tester, yet you’ll still catch the bug as you’re developing.
• Place all non-html output variables into a single object, it doesn’t matter if the input comes from the user, or the database, it still needs to be encoded, okay a number should never need encoding, but there’s little lost to doing so anyway and you’ll reduce the risk from untrusted data. You can make this object only output encoded content, e.g. in javascript, you could use something like:

   function safeString(str) {  this.value=str; } safeString.prototype.toString=function() {  return htmlencode(this.value); } safe=new safeString(\"<script>alert(1)</script>\");document.write(safe);

  Of course you can still make the mistake and not use your object, but it should be much easier to spot the bug early in the process.

• This is mainly the testers job of course, but in an idle moment you should change the query string of any page to include a load of the bad characters, and just see if the page is happy, they should appear just like any other character does.

These methods won’t stop all security problems, you’ll still need to think properly about security, but they at least make you a step above the current Google or Yahoo developer.

Google Base arrived recently, sharing the same domain as gmail, so cross site security holes in Google Base will allow access to all the gmail emails, as well as XSS phishing attacks using the google brand. Of course as you would expect for a new product from a major internet company, there’d obviously been no security testing whatsover and there were trivially obvious XSS holes in it.

Like the yahoo programmer last week, the incompetent google base programmer had simply taken a parameter from the querystring, and written it unencoded into the document. So a query http://base.google.com/base/search?a_n427=<script>alert(1)</script>&a_y427=0&a_s427=0&a_r=2 performed the alert, this was fixed about 5 hours after I reported it, showing again that google don’t care about the security of our data enough to not release clearly insecure software.

Like last year googles response to the email report was nothing, there wasn’t even an autoresponder on security@google.com, so other than by watching for it to be fixed did I learn that it was at all. Like the gmail security flaw google appear to have a complete silence approach to security, I guess they think what the public don’t know can’t worry them. I can’t understand the motivations behind not acknowledging and thanking a reporter of a security flaw, the alternative for the people who find these flaws are to get rich abusing them, or publicising them allowing other people to get rich abusing them. Surely “thanks for your bug report, we fixed it” email is a small price to pay for not having to hire your own QA team?

Google Base is beta, so bugs are perhaps to be expected, but I can’t understand why Google don’t have at least some security testing, would the publicity of a breach not be a PR disaster for them? Like I said last week, host the Beta on a seperate domain.

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.