Browser makers open local storage hole in HTML5
A slip-up in the implementation of HTML5 on Chrome, Opera and Internet Explorer can be exploited to fill users’ hard drives, according to a 22-year-old Web developer from Stanford. Feross Aboukhadijeh has posted a proof-of-concept of the exploit here and a demonstration page here. He explains that HTML5 is designed to allow …
This topic is closed for new posts.
Cookie Size
Madness. All a cookie needs to store is be a unique identifier. Why 10Mbyte? 10 bytes is lots.
Re: Cookie Size
This isn't a cookie, it's HTML5 local storage. It's for storing data locally, not for uniquely identifying a vistor.
Re: Cookie Size
The article says cookies up to 10Mbyte. Actually I don't want websites to store anything else, unless I go "File Save".
10 bytes is 80bits.
That's 1208925819614629174706176 possible visitors for each website.
What is this? HTML planning for a universe of visitors that it needs 80 Million bits of storage per visitor on your own machine?
Re: Cookie Size
Indeed, most cookies take two or three bites. Ten bites is a pretty big cookie. 10 mega-bites must be those cake-sized cookies that really shouldn't count as cookies at all.
Re: Cookie Size
The article might say "cookie", but last time I tried writing a "cookie filler" page, the end result was that the cookie got as utterly huge as I had patience to wait for, but the web browser then failed at subsequent efforts to read any page from that site.
HTML5 local storage definitely ain't no 2kb text file.
Re: Cookie Size @oninoshoko
The label says "cookie". That is plaintext whichever way you look at it. That's ten friggin' MB of plaintext we're talking here. The old adagio "If you can't do it in 64kb, it's not worth doing." comes to mind.
The mind boggles.
Re: Cookie Size
Thereby missing the point.
HTML5 adds the concept of local storage so that more sophisitcated off-line web apps can be developed.
Writing a simple app in HTML, CSS and JavaScript is much easier and more portable than trying to do it with the more traditional technologies. What has been missing is the ability to store data.
The problem with true cookies is (a) by design, they are limited in capacity, (b) they are cumbersome in JavaScript, and (c) cookies are always sent back to the server. Off-line storage is easier to work with, and allows real data to be stored locally, perhaps permanently or perhaps you go back on-line and sync with a server.
Cookies are rightly used to store identifiers or perhaps unimportant user options. Off-line storage make the transition to creating a real web application.
Re: Cookie Size
"Off-line storage make the transition to creating a real web application."
Off-line storage almost makes it a local app. Cue lots of bloaty apps that rely on storing half their runtime data on your hardrive. Awesome.
Anyway i thought we were all supposed to live in clouds these days...
Re: Cookie Size
The cloud? Sure, if you can guarantee that you will always have a high speed, low latency connection;off you go with no local storage.
The server-client paradigm is as old as the hills, yet we keep making the same mistakes.
That's how it starts
"10 bytes ought to be enough for any cookie" --Mage, ca:2013
So says a snarky .sig from the future.
Re: That's how it starts
"It's got 512K of RAM. Nobody could ever need more that 640K of RAM so why would we make memory chips of 1MB"
After all the fuss about the JVM re performance, bloat and security concerns, funny to think our browsers are no different really. Just another VM waiting to leak.
2 Webkits and a Dog
Well there you have it.
What does Webkit have in common with IE?
Re: 2 Webkits and a Dog
not sure really.
I guess Trident really can cause a lot of damage afterall...
The only good thing about html5 is that it's killing flash. My concern is that all these crap flash 'developers' will merely become crap html5 developers and my machine is going to pay the price.
HTML5
Since you don't like being able to do more on web pages, may I suggest something like IE8? That should stop that pesky HTML5 humbug coming onto your computer nicely. :)
"My concern is that all these crap flash 'developers' will merely become crap html5 developers"
There's already enough crap PHP, C#, VB, Python etc. developers banging out shit HTML5. A few more from the Flash camp will hardly be noticed.
Flash?
block it in your browser of choice, remove any residuals from your harddrive. Enjoy the silence.
Kill Flash = kill >50% of failed page loads on a slow connection.
Bill Gates, Microsoft, 1981
"No one will need more than 637 kb of memory for a web browser—640K ought to be enough for anybody"
And now we're talking about 10MB of storage per web site! How the times have changed.
Re: Bill Gates, Microsoft, 1981
Misattributed.
http://en.wikiquote.org/wiki/Bill_Gates#Misattributed
Re: Bill Gates, Microsoft, 1981
Thanks for the correction and thumbs up to you.
Sigh
Already had to correct this on Slashdot. The latest stable version (released Feb 9th, and probably earlier versions too because the feature has been there for a while) of Opera is NOT affected. Why? It asks you what to do:
http://www.ledow.org.uk/Opera.jpg
Seems the same misinformation on the original site propagated through to Slashdot and The Register in spite of two independent sets of editors/journalists.
Re: Sigh
Actually, Opera IS affected. The limit should default to 5MB per orign, or set of related sites (i.e, all x.domain.com/y) However, testing with the demo page shows Opera accepting approximately 74-76MB before prompting. The prompt that comes up states that the referenced site -- not the master domain, but the subdomain was defaulted to 5MB. That should not have happend. The master domain (domain.com) should have been allocated a default of 5MB, not the subdoman (x.domain.com).
Given that, Opera should only accept 5MB from the original demo page before prompting. The fact that it accepts over 70MB indicates that Opera is NOT treating the storage request properly, and that the demo page is likely using approximately 15 subdomains or a psuedorandom subdomain selection that results in enough collisions to meet Opera's limits after approximately 75MB.
Re: Sigh
There is no rigorously specified default in the standard. The standard even admits that it's pretty much an arbitrary number to pick.
The point is that 76Mb of disk space is NOTHING nowadays and not going to fill up your hard disk (no more than just ordinary caching of web content, for example, which can default to Gigabytes of storage). It certainly won't crash your computer unless it was already going to crash anyway (76Mb of free space is just untenable on a modern system, no matter the OS - it's just not enough room to do anything, even temporary files or swap file expansion space - and you're system is going to crash).
Opera detects the situation, prevents it from getting silly, and asks the user. The fact it uses a different standard of "silly" is neither here nor there, because it's still a practical standard of "silly".
Re: Sigh
But if Opera followed the standard as written, it would stop and prompt at 5MB -- in fact the prompt that does show up indicates that this is the intent.
The break from standard that is the underlying issue is not the default amount of storage allocated, but the fact that subdomains are supposed to be treated as the same origin as all other subdomains of the same domain., and that is not done in the current stable version of Opera.
As I explained, the 76MB "limit" in this case is caused not by Opera, but by the way in which the filldisk demo script uses its subdomains. Since the number of possible subdomains for a given domain is practically infinite, a more intelligent script could use Opera to fill a drive.
More to the point, the default setting for Opera is 5MB, meaning that sites can already use 15 times the defined (in this case by the software, not the standard) limit.
Couple of questions:
1) Does turning off DOM storage prevent this?
2) Does it affect mobile browsers, thus potentially leading to large data bills?
Large data bills?
I thought the idea of local storage was so that data could be stored locally and not sent backwards and forwards to the server for every page.
Don’t worry though - your network provider will know how to squeeze every last penny out of you
Re: Large data bills?
While that is part of the intent of the standard, there's nothing* to stop a script from downloading data indiscriminately into the local storage, thus filling up your storage and running up a large network bill.
But there's nothing to stop the script from doing the downloading bit and just discarding the data, either. So the storage bit doesn't in itself add significantly to that risk.
*Except perhaps a proper implementation which limits a given origin (including subdomains) to a sufficiently low amount of storage, such as 5MB.
Cloud storage
I can see this being used by botnets and rented out as cloud storage.
Re: Cloud storage
Why bother? If a botnet has your comp, why slum for a few to several Mb of localStorage that could be deleted on every exit of the browser if one has such things set up as opposed to gigs of harddrive?
It has been well known for some time that the memory limit can be expanded with a prompt, this simply gets around that. So at best a little browser patch is in order.
On the other hand as mentioned before, localStorage can be used for offline apps quite effectively. I have managed to compress a massive DB down to less than 2Mb (as a nested JavaScript array) and the accompanying JavaScript, CSS, and HTML are under 100 kb. Even with the 2.5 Mb limit, this leaves months worth of space for user data available without having to communicate with the web, and the app actually pops like Apple commercials after the edited sequences across all platforms.
Although, I will assume you are joking.
Fill me up?
I don't know about massive cookies, but my El Reg screen is currently awash with wall to wall, giant, orange adverts for MS Office 365!
My eyes!
I trust Eadon is enjoying this too, should he get served the same adverts.
Re: Fill me up?
Eadon doesn't see adverts because he's using IE10 under Win8 with EasyList TPL.
(note - he probably isn't because installing a tracking protection list by clicking on a link is probably too advanced for the poor little lad. However, the 89 year old gentleman who lives over the road from me uses exactly this setup and never sees ads, except [for some reason] on Facebook which he no longer bothers with).
Re: Fill me up?
What there are adverts? Damn, I'll have to turn off NoScript.
Re: Fill me up?
You need an ad blocker. Thats what i do. Otherwise i want to stab forks in my eyes.
Security vulnerablity
Firefox is immune. IE is vulnerable. QUELLE SURPRISE!
IE FAIL
Re: Security vulnerablity
Safari and Chrome are vulnerable.
EADON FAIL.
Re: Security vulnerablity
@dogged my non-technical friend, so? Tis still an
IE FAIL
Re: Security vulnerablity
I'm sorry, I'm clearly not "technical" enough to note that the browser based on closed-source Trident and the browsers based on open-sourced KHTML fail in exactly the same way for the exactly same reason and determine that it's a fail only for IE.
You retard.
Re: Security vulnerablity
"IE FAIL"
Even so, it is a minor (and shared) fail when viewed in context of the opportunities for nefarious activity that HTML5 presents.
CSRF, thick feature vulnerabilities, DOM based XSS, client cache poisoning, stored XSS, client-side SQL injection. The list of potential attack vectors within HTML5 is quite extensive and platform independent.
Re: Security vulnerablity
Eadon, try feeding this to FF from an html5 doc or the web console. YMMV with the numbers or platform though. (Here on a quick test, it usually* burns at about 3.2GB mem consumption)
for (i = 0; i < 5000000; i++) {
sessionStorage.someData += '0';
}
* ~90% of the time.
IE fail?
I appreciate you used the word "cookie" to try and give non-savvy users a clue about what's happening, but look at all the retardation you've caused in the comments. Cuhh.
This is not "cookies", in the slightest. This is "local storage", a very different thing with a very different purpose. Hence it being different. Cuhh.
So it can maliciously fill disk space with multiples of MB. That's bad.
Now take it one step further - maliciously fill disk space with multiples of child porn. Suddenly such vulnerabilities take on a whole new danger level.
HTML 5 local storage must be disabled, think of the children!
Just the beginning
Everyone already freaks out about cookies but this API opens a whole new kettle of fish. Well, a much larger old kettle of fish.
You ain't seen nothing yet! This will be the primary attack vector on peoples' machines, 10MB is more than enough data to do damage with.
This topic is closed for new posts.
