Live data from Hacker News

HTML5 localStorage allows sites to fill up users' hard disks

feross.org

61–70 of 191 posts

Re: HTML5 localStorage allows sites to fill up users' hard disks

#62
post #44

Well this is frightening. You don't even need to create subdomains since basically anyone with wildcard subdomains enabled can do this without a sweat. All you need is a random number generator and rewrite x.domain.com to domain.com and the browser is none the wiser. Though I can't quite imagine why anyone would want to do this to some random stranger. Unless you knew the visitor or had some means of personally ident…

Pretty bad for a company if someone injects a HD-filling script to their site.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#63
post #50

So. The question I'm asking myself now is how to fix this. Giving .domain.com a shared quota will allow one tumblr or github pages user to monopolize all storage, effectively removing local storage for this kind of scenario (also removing it for the host which is even more annoying). A maybe workable solution would be to only allow creation of new keys for the first-party origin. What I mean is that whatever.example.…

Any kind of DOM storage (cookies, localStorage, IndexedDB, etc.) is ephemeral. The browser needs to decide the maximum amount of disk space that it wants to consume, and then when it hits that limit, it needs to start throwing away (garbage collecting) some of the data based on some policy like LRU.

If the web app really needs permanent storage then that permanence of storage needs to be granted explicitly by the user.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#64
post #60

Some analysis of how this works, 1. The main page contains an iframe which serves this script: https://github.com/feross/filldisk.js/blob/master/static/fra... 2. This script writes a 2,500,000-length string to local storage, which should occupy at least 2.5Mb (probably much more). This matches the maximum storage per sub-domain. 3. This script then reloads the iframe on a different subdomain but the same script. GOTO…

Yep, I included lots of comments in the source code so that people could check it out and learn how it works: https://github.com/feross/filldisk.js

Thanks! Nothing better than well documented code. I found it very easy to follow.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#65
post #50

So. The question I'm asking myself now is how to fix this. Giving .domain.com a shared quota will allow one tumblr or github pages user to monopolize all storage, effectively removing local storage for this kind of scenario (also removing it for the host which is even more annoying). A maybe workable solution would be to only allow creation of new keys for the first-party origin. What I mean is that whatever.example.…

There really isn't an easy way to avoid this problem even if you follow the standard fixed quota per domain and subdomains don't count policy. You could just embed iframes to diskeater1.net, diskeater2, etc and fill up the disk that way.

In the end, the problem is that one page can itself infer to other domain / subdomains in its document and those can execute and utilize localstorage. They have to, though, so you can embed an html5 game in your blog from some other site that you liked. It comes with the territory.

Sadly, it seems like the best answer is the horrible UX'd prompt - "do you want to allow x.y.z to store local content on your computer?" the same way you have to verify downloads and know exactly what you are running locally.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#66
post #14
post #3

So apparently this is where you file IE bugs http://connect.microsoft.com/IE - i'm not sure if it's expected or ironic that it's broken. Great find btw!

http://connect.microsoft.com/directory/non-feedback It's actually on the list of items not currently "receiving feedback" whatever that means.

That is because MS just released IE10 for Win7.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#67
post #52
post #47

Earlier quoted context omitted.

Sorry, maybe this is obvious, but — how do you fill up a remote HD with just an IP and hostname with nmap and friends?

Well, I meant you can use these tools to gain access to the remote machine to do some real damage. Nmap and friends are usually for finding running services, list of open ports, knock on a few doors (run some queries?) etc... and if someone were to gain access to a machine this way, filling up their hard drive may not be on their list of priorities. Unless incrimination was the intention.

Compromising an up-to-date machine is usually a bit harder than just pointing nmap at it and enumerating running services.

Getting someone to visit a web site is relatively easy.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#68
post #65
post #50

So. The question I'm asking myself now is how to fix this. Giving .domain.com a shared quota will allow one tumblr or github pages user to monopolize all storage, effectively removing local storage for this kind of scenario (also removing it for the host which is even more annoying). A maybe workable solution would be to only allow creation of new keys for the first-party origin. What I mean is that whatever.example.…

There really isn't an easy way to avoid this problem even if you follow the standard fixed quota per domain and subdomains don't count policy. You could just embed iframes to diskeater1.net, diskeater2, etc and fill up the disk that way. In the end, the problem is that one page can itself infer to other domain / subdomains in its document and those can execute and utilize localstorage. They have to, though, so you ca…

Prompt for origins that have never been visited directly by the user.

Re: HTML5 localStorage allows sites to fill up users' hard disks

#69
post #62
post #44

Well this is frightening. You don't even need to create subdomains since basically anyone with wildcard subdomains enabled can do this without a sweat. All you need is a random number generator and rewrite x.domain.com to domain.com and the browser is none the wiser. Though I can't quite imagine why anyone would want to do this to some random stranger. Unless you knew the visitor or had some means of personally ident…

Pretty bad for a company if someone injects a HD-filling script to their site.

So then this would really be handy in a mud-slinging campaign. Maybe against a competitor. Any visitors would be treated to a massive drain on storage and other delights, but then the victim would still need to have multiple subdomains and/or wildcard subomains enabled.
Post reply on HN