Closed Bug 758296 Opened 12 years ago Closed 11 years ago

XHR with responseType blob can be used to consume all the user's disk space

Categories

(Core :: DOM: Core & HTML, defect)

10 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: briansmith, Unassigned)

References

Details

(Keywords: sec-other, sec-want, Whiteboard: [sg:dos])

+++ This bug was initially created as a clone of Bug #725993 +++

There is a LOT of related discussion in bug 725993. Besides the performance issues with the STORE_ON_DISK_AS_FILE mechanism waiting on the cache lock on the main thread, there is a security issue: when STORE_ON_DISK_AS_FILE is used, we do not enforce any limit regarding the size of the entry. This means that a website can use XHR with giant blobs to force Firefox to eat all the user's disk space. This is a serious issue because many operating systems behave very badly when they run out of disk space and it can be difficult, or in some cases maybe even impossible, to recover from a full disk. Also, when this happens, it could become impossible for the user to save any unsaved work.

I talked with Jonas about this and he said that we're working on a way to safely allow websites to use disk space beyond the limits we have currently set (for IndexedDB and AppCache, for example) and that might be relevant to this work. But, that work might not be done until Q3 or after Q3.

I suggest that, until then, we simply enforce the 50MB cache entry size limit here. One way to do that would be to stop using STORE_ON_DISK_AS_FILE in XHR. But, Jonas said it is important for XHR to have some mechanism to tell the cache to keep the file accessible for the lifetime of the Blob object, so that the blob object can access it as necessary. I think this is just a matter of having XHR keep the cache entry open as long as it needs it.
(In reply to Brian Smith (:bsmith) from comment #0)
> object, so that the blob object can access it as necessary. I think this is
> just a matter of having XHR keep the cache entry open as long as it needs it.

But, what should happen if the user does "Clear Recent History" while the blob is open? Should we delete the file and cause the blob to stop working, or should we still keep the data on disk?
Part of the the patch in bug 725993 might resolve this, because it removes the use of STORE_ON_DISK_AS_FILE by XHR. But, I do not know if that is an acceptable solution.
FWIW, I don't care what happens if the user clicks "clear cache" UI while a blob is open. That will happen rarely enough that it's ok if sites break when the user does that.
Keywords: sec-other, sec-want
Whiteboard: [sg:dos]
This is fixed by bug 725993, no?
Is there any way to have a disk-backed blob without using the now-removed store-as-file mechanism? If not, then I agree it is fixed by bug 725993 and that we should mark the bug (RESOLVED WORKSFORME, Depends: 725993, cleared security-group flag).
No, XHR will no longer create a disk-backed blob.
(I have no privilege to clear the security-group flag)
No longer blocks: 725993
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 725993
Resolution: --- → WORKSFORME
Group: core-security
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.