Feeds

back to article 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 …

COMMENTS

This topic is closed for new posts.
Silver badge

Cookie Size

Madness. All a cookie needs to store is be a unique identifier. Why 10Mbyte? 10 bytes is lots.

7
3
Silver badge

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.

5
0
Silver badge

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?

2
3
Irk
Joke

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.

7
0

This post has been deleted by its author

Silver badge

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.

0
0
Silver badge
FAIL

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.

2
0

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.

2
0
Anonymous Coward

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

0
0
Silver badge

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.

1
0
Anonymous Coward

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.

4
0
Silver badge

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"

0
0
Anonymous Coward

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.

0
3
Silver badge
Facepalm

2 Webkits and a Dog

Well there you have it.

What does Webkit have in common with IE?

0
0

Re: 2 Webkits and a Dog

not sure really.

I guess Trident really can cause a lot of damage afterall...

0
0
Alert

What's the Opera result again?

0
0

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.

2
1
HMB

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

2
0
Anonymous Coward

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

0
0
Silver badge

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.

0
0
Bronze badge
Happy

Why not use Lynx?

No flash, no HTML5, no images...

1
0
Windows

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.

2
4
Irk
Holmes

Re: Bill Gates, Microsoft, 1981

Misattributed.

http://en.wikiquote.org/wiki/Bill_Gates#Misattributed

4
0
Thumb Up

Re: Bill Gates, Microsoft, 1981

Thanks for the correction and thumbs up to you.

1
0
Bronze badge
Thumb Down

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.

0
0
Silver badge
Boffin

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.

1
0
Bronze badge

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

0
0
Silver badge

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.

1
0
Anonymous Coward

Couple of questions:

1) Does turning off DOM storage prevent this?

2) Does it affect mobile browsers, thus potentially leading to large data bills?

1
0
Silver badge

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

0
0
Silver badge
Happy

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.

0
0
Silver badge
Coat

Cloud storage

I can see this being used by botnets and rented out as cloud storage.

0
1
Bronze badge
Pint

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.

0
0
Silver badge
WTF?

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.

0
0
Silver badge
Trollface

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

1
1
Bronze badge
Facepalm

Re: Fill me up?

What there are adverts? Damn, I'll have to turn off NoScript.

3
0
Bronze badge
Angel

Re: Fill me up?

You need an ad blocker. Thats what i do. Otherwise i want to stab forks in my eyes.

0
0

This post has been deleted by a moderator

Silver badge
FAIL

Re: Security vulnerablity

Safari and Chrome are vulnerable.

EADON FAIL.

6
1

This post has been deleted by a moderator

Silver badge

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.

3
0
Anonymous Coward

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.

0
0

This post has been deleted by its author

Anonymous Coward

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?

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

3
0
Silver badge
Black Helicopters

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.

0
0
Silver badge
WTF?

HTML 5 local storage must be disabled, think of the children!

3
0
Bronze badge

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.

0
0
This topic is closed for new posts.