2fca Jibbering Musings » SVG-y-Stuff

Archive for the 'SVG-y-Stuff' Category

« Previous Entries

Public betas risk all our data

Saturday, November 5th, 2005

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.

Posted in General, SVG-y-Stuff | 1 Comment »

htmlnaut - foafnaut in html

Tuesday, October 11th, 2005

foafnaut is the SVG viewer of foaf data, unfortunately the current data doesn’t get updated as I’m trying to convince other scutter people to provide the data. I’ve just put together an HTML version, this does much the same as the SVG version, but not as impressively, there’s no sproings linking the blubs for a start. (A blub is the thing that represents a person, a sproing the line between them.)

In Internet Explorer using VML, or in Deer Park using SVG, there are sproings, the lines are drawn in. This shows very well how well mixed namespace documents can work, html is good at marking up the information panel, but atrocious at drawing the lines - especially ones that are animated. Hopefully soon Opera and Safari will get scripted SVG - Opera still has static - so I’m not going to attempt an alternative with lines for them, just wait until the UA’s catch up with the script.

The SVG version is still much richer, there’s some automatic layout to keep blubs away from each other, the dragging is more reliable, the graphics much better, but for a simple taster the htmlnaut isn’t too bad.

Posted in General, SVG-y-Stuff | 2 Comments »

The Javascript Archive Network

Thursday, July 14th, 2005

Javascript Archive Network is a new site which claims to be “a comprehensive resource for Open Source JavaScript libraries and software.”, unfortunately simply accessing the site in my IE6 generates two script errors. So it’s not a good start. The authors also desperately need to set a background colour - people, please stop making this mistake!.

So what’s the error, the first is that the HTTP variable is just used without being checked that it exists first, a common error, but one scripters must stop making if the quality of their scripts are going to go up, anyway it’s unfair to criticise the page, it’s really the scripts that matter - So I’ll probably criticise those instead, it’s what normally seems to happen in this blog…

Well I’m not, it’s got a lot of crap in it, it’s got a some good in it, just like CPAN has, what’s really missing is some way to identify the good stuff from the bad stuff, CPAN you can generally do this simply because of the longevity and the breadth of the archive. Hopefully the same could happen with JSAN, but until, maybe there should be some sort of review process on scripts, so that competent scripters get in there and highlight bad things in the scripts. Of course that’s difficult to organise, hopefully adding a comments system to the packages would be a quick cheap way of at least allowing people to comment on scripts, so I’m off to ask the founder bod.

2aaa

Posted in General, SVG-y-Stuff | 12 Comments »

Unobtrusive javascript…

Wednesday, June 22nd, 2005

Unobtrusive javascript is beginning to be talked about more, unfortunately it’s not as easy as the proponents often talk about… For example, one of the truly excellent scripters, PPK gets it wrong on his homepage…

I was visiting his site in my regular IE6 on windows XP SP2, it’s not a default config, but it’s still an IE6, and I instantly start with a script error, before there’s any content. W3CDOM is undefined is the error, so why does this happen? Well there’s 2 reasons it could happen, W3CDOM was defined in an external script file, so if the script file wasn’t downloaded, it would indeed be undefined, or if the mime-type of the script wasn’t supported by the browser, again the script wouldn’t be executed. In fact it was the 2nd one - <script src="index.js">&ltl/script> was the code, and then the index.js file was returned with the mime-type of application/x-javascript, a mime type IE does not consider as javascript - not unreasonable, it’s an x-type and so shouldn’t be used on the web.

IE is bad in that <script type="text/javascript" src="index.js"> would’ve been executed, which is a good thing to know as it means HTML validity would’ve solved the problem for us, as the validity error of the lack of a type attribute would’ve solved the error, so if you’re going to try to write unobtrusive script, valid documents really can help! Of course that still wouldn’t’ve solved the problem of if the index.js wasn’t downloaded for some reason - blocked by a proxy or network failure or whatever, so the script inside the document should also make sure that it works even if the script doesn’t work. That would be easy here, use typeof to check the W3CDOM variable is defined, or go if (window.W3CDOM) or include fallback script inside the first script block.

IE also gets it wrong and accepts the file if the index.js is loaded from the cache, and not from the remote site, this means that if you’re trying to recreate this, you’ll need to clear your cache before accessing it in IE.

Incidentally, whilst we’re looking at the script http://www.quirksmode.org/index.js we can spot a few other errors (I’m highlighting purely to show how tough unobtrusive script is, you’ll be able to find lots of similar errors in my scripts!) he uses the navigator, top, document and location objects without checking they exist - none are more than a de-facto standard, and if you’re really going to make sure your script can’t error, because errors are certainly not unobtrusive! then you should perhaps check for them first. Next is the use of top.location.href - the problem here is that if the location is on another domain, even setting the location.href has been known to cause “access denied” errors in IE6, just setting top.location='/index.html' will work in all the likely browsers and doesn’t suffer this same problem.

So this post was meant to discuss The single correct use of document.write, but I’ll guess I’ll do that later, the toughness of unobtrusive javascript was the topic instead.

Posted in General, SVG-y-Stuff | 2 Comments »

Ajax… Or how an old idea needs new marketing.

Monday, March 14th, 2005

PPK talks about Ajax, and there’s some talk of exactly the history of the concepts, but even in the comments they’re far from going back far enough.

Ajax itself is nothing new, Everything was in place to do it in IE in 1999 once IE5 shipped (or before you installed MSXML) - 2001 brought us it in Mozilla, when XML HTTP Request arrived. The dynamic HTML etc. needed had been there for years. Of course in reality, you don’t need the xml http request object, iframe/ilayer based systems are fine, and Brent Ashley had a nicely packaged version of this in 2000 with JSRS, but the general techniques were in use before that.

In 1998, Microsoft had offered us a Java based Remote Scripting solution.

In fact even before DHTML, Frames and basic forms had given us the possibility to update pages without the user seeing the refresh - see for example a usenet post from March 1996 discussing it.

So the concepts have existed since the beginning of scripted webpages, well since Netscape 3 anyway. The idea isn’t new.

So what took so long?

The obvious first question is why if it’s been around over 9 years, are we only just seeing prominent sites taking up the concept - I think there’s a number of reasons for this:

  • There’s not many good scripters about, and they’re not always in the right places in the company, most projects stick with what they know, it’s sensible, it’s safe - if you don’t know how easy partial page updating is, why would you bother?
  • Server side knowledge have dominated web development projects, with their experience of server side scripting - it’s simply taken many years for client-side scripting to be seen as a seperate discipline, needing seperate skills, and something to specialise on.
  • The monoculture didn’t exist when there was budget. In the last boom of web-development we didn’t have a single browser that dominated the web, we had a much riskier landscape that made development harder. The testing resources, the development resources, all of this needed to be much higher in that environment. Then during the rise of the IE monoculture, the budgets were constrained, even more reason to stick with what you know and what’s safe.
  • The dominant player who didn’t have a browser, Google had the market dominance to create GMail, and rather than having to write and test on the 4 browsers they wanted to support, (to get coverage on non win32 platforms and avoid the bad PR), all they’ve had to do is use their market position to force Safari and Opera to follow the IE specifications, that of course wouldn’t’ve been possible if Hotmail went for the partial update version.
Will it revolutionise the world, or is it just hype?

Ajax is hype, there’s nothing wrong with that though, the product managers and marketing people need a word they can understand, “partialling updating webpages using xmlhttprequest for the server communication giving the user more responsive UI’s” simply isn’t an understandable pitch. So it needs a name, it’s a poor name, seen as verry few developers will use the XML or XHTML standard in it - XML simply because it’s too slow, and too complicated - JSON is simply simpler and faster, and XHTML simply because no-one ever uses it other than in a cargo-cult way, they certainly won’t care if it’s valid.

Even then though, I don’t think it’ll revolutionise the world, a lot of companies will blow an awful lot of cash attempting it, the current problem is still the woeful lack of competent scripters who can write such interfaces and have them degrade to an accessible, or even usable system if people change a single setting. Many of these companies will of course be putting their server guys on it, and a very out of date copy of DHTML Bible will generate atrocious, unmaintainable sites. Some might get lucky and have a competent scripter on board - there are some of us out there, but there won’t be enough to make it some great new age of web-development. Mostly we’ll see more complicated systems that don’t need the features, people are happy to move to a new page to get their flight search results, they’re only doing it briefly.

Now is certainly not a good time, we’re about to see the monoculture break down, IE7 will arrive and have a whole new set of bugs and opportunities - that’s fine for Google of course, they’re in the compatibility tests I’m sure. That’s not fine for new projects starting now, they’ve just got an open ended risk that all their work will need debugging and re-writing just as IE7 arrives. MS have traditionally done a pretty good job with backwards compatibility, but the more intensive you use javascript, the higher the chance that you’ll get hit by a bug.

Ajax is certainly hype, but the ideas are not new, and will always have their place, they just aren’t quite the all encompassing space that most people seem to think they are, it’s only in niche areas where people are spending a lot of time on a page, with only parts of it updating - email, auctions etc. The majority of sites simply won’t need it, validate a form with Ajax - you’re crazy, you’re wasting your resources…

2720

Posted in General, SVG-y-Stuff | 5 Comments »

Javascript Triggers

Tuesday, February 1st, 2005

PPK has written up an article on alistapart about javascript triggers, it’s interesting, unlikely to be new to many, but that’s alistapart generally. The general idea is that you should include custom attributes or use ID in your HTML to allow you to add scripted behaviour to the document.

However there are a number of important problems not mentioned. If you add behaviour to your document outside of the HTML, there’s a time period where the user can interact with the HTML elements without the proper behaviour, either they’ll trigger the no script fallback - which could be annoying they get a much worse user experience, and you’ve wasted your time writing the script. Or as is more likely for the majority of script developers these days, they’ll end up with nothing happening.

The delay in behaviour loses one of the key elements of UI that of consistency.

You can of course author your script in such a way that this isn’t a problem, however to do that you can’t abstract out your scripts, they have to be inline next to the elements and immediately follow the HTML elements they’re modifying, the onload event is much too late. There is another alternative, that of hiding your content until such time as everything’s been rendered and the behaviour attached, this is far from trivial - how can you be sure you can show it again in a degradable manner? - and of course it makes your site seemingly much less responsive, so I think that is worse.

Seperating script and HTML simply isn’t practical in todays mark-up languages, even if it’s desirable. Simple onsubmit form validation might cut it, just about, because the user is unlikely to interact with the form enough until after the behaviour has been attached, but the more complicated validation that provides real-time feedback, that’ll be down the same problem of “onload=’someformelement.focus()’” where most users are well into the field before being viciously snapped back to the first.

Techniques like XBL, or HTC’s are practical future ideas of how proper seperation of behaviour can be achieved, but I don’t think a retrofit onto HTML is a good idea yet.

Posted in General, SVG-y-Stuff | 7 Comments »

The meta lathe that isn’t

Tuesday, December 14th, 2004

Over on the meta lathe, there’s the suggestion that the programmable computer isn’t something people should be trusted with, and more importantly don’t need to be trusted with. What it misses is that the reason we have computers that can do anything and programs which can do 20 times more than any of us ever want to do individually. Is that the combination of things that each of us want in a platform is different, sure everyone uses a spreadsheet, an email client and a wordprocessor, but then there’s games. The how to juggle program Aunt Maud recommended, the Astronomy assistant etc. are all used by a few people, creating a device with all these combinations that people would want would be impossibly expensive, and would almost certainly rely on deliberately hobbling devices, once the applications had been installed - no-one is going to want that.

Posted in General, SVG-y-Stuff | No Comments »

Google Cookie lets you go anywhere

Friday, October 29th, 2004

Not surprisingly there’s more announcements of google’s holes - they’ve fixed Aranzulla’s by the looks of things (by stopping any google desktop results from appearing in a web search, good choice) but they’ve still not fixed my google desktop one, although it’s now not exploitable unless you can first get in to the localhost so - look at what happens when getting a cached email message, the search string is written unencoded into the page - </script><script>alert(1)</script> will execute the script, tough to exploit without other bugs, but still shows poor programming practices.

The recent hole again shows they don’t really understand basic security principles - the cookie you get to authenticate you, lasts forever, isn’t tied to ip address or anything, it’s all you need to view gmail, google or anything. People who looked at my sample exploits will note I captured the cookie as part of one of the POC’s - don’t worry if you looked, I won’t be doing anything with the cookie.

The Google Cookie problem is pretty obvious, I’d considered it, but not bothere to check figuring that google couldn’t be that stupid to only use a cookie for authentication without basing it on a hash of other details of the request, I should never have underestimated Google’s ability to get security wrong.

Posted in General, SVG-y-Stuff | 1 Comment »

Trying google security again.

Tuesday, October 26th, 2004

Well the Google fix didn’t fix all the original issues I reported, I didn’t mention them in the exploit page as they only apply to a few minority browsers, but they’re there - so I’m trying security@google.com again again, this time copying in two people at google who got in touch.

Not that I hold out much hope, the Google security guy hasn’t responded in the last 5 days to my simple request of how to actually report flaws since the email address doesn’t work (and I’ve heard from two other people who have had a similar lack of response after emailing them)

Hopefully Google will start responding and taking security reports seriously, I don’t hold out much hope, but if the flaws that exist in google desktop are made public, Google won’t be able to get it fixed in hours, people will be stuck with the old flawed, exploitable versions of Google Desktop they have now. If you’ve still got Google Desktop, Uninstall it now!.

Oh actually it looks like Salvatore Aranzulla has already publicised the Google Desktop flaw - whilst not quite the same as the one I found, it comes from the same root cause - Google developers writing untrusted data from the querystring straight into the page without encoding it.

Google, 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. At the moment it’s ridiculously easy to find exploits in Google, and they don’t seem to be taking it seriously.

Users - uninstall Google Desktop, make Google a “Restricted site” in IE so script is disabled go to “tools - security - restricted sites” and add *.google.com, other browser users do the same, and start looking for different search or email solutions.

262b

Posted in General, SVG-y-Stuff | 9 Comments »

Exploit working again for some?

Thursday, October 21st, 2004

I seem to be getting what appears to be successful google exploits coming in again, I don’t know if this is because of proxy caches, or some google boxes haven’t been patched, or just because the logs are making other requests look like google ones. But a reasonably steady request for the javascript files with google referrers. and then subsequent hits to the steal uri just like the pattern when it was working for me are coming in.

Still appears patched for me though - Netcraft however say they’ve found another though, not surprising, but lets hope google are little faster at fixing it this time - Turns out my 2 years was actually an undersestimate, in May 2002 I posted it to usenet, and that was months after I’d let google know.

Posted in General, SVG-y-Stuff | 6 Comments »

« Previous Entries
0