Firefox 3.6/HTML5 File Objects Security Review: Difference between revisions

Jump to navigation Jump to search

Firefox 3.6/HTML5 File Objects Security Review (view source)

Revision as of 00:56, 8 August 2009

7 bytes removed ,  8 August 2009
→‎Security and Privacy
No edit summary
Line 17: Line 17:
* '''Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.'''
* '''Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.'''
**There was talk within the spec about the (previously modal) FileDialog constructed perpetually within a non-terminating loop and harassing the user to choose a file. There should be a number of fairly straightforward ways to circumvent the issue, one of which includes making the new FileDialog window NOT modal (or perhaps tab-modal).
**There was talk within the spec about the (previously modal) FileDialog constructed perpetually within a non-terminating loop and harassing the user to choose a file. There should be a number of fairly straightforward ways to circumvent the issue, one of which includes making the new FileDialog window NOT modal (or perhaps tab-modal).
**With regards to file drag n' drop, there was talk about the possibility that an unintentional drag without an ending drop could cause unwarranted and unexpected access of a user's file data. For instance, imagine some extension has proper privileges to execute chrome code. If a user dragged code from one side of the desktop to the other side, and passed through the browser window, the chrome caller would be able to detect a drag event and instantiate a DOMFile object and extract the contents, without the user's knowledge. This issue was alleviated by populating the .files attribute of a dataTransfer *only* on a drop event, and not on a dragstart event, making it more apparent to the user as to the opportunities when file data could ever be retrieved.
**With regards to file drag n' drop, there was talk about the possibility that an unintentional drag without an ending drop could cause unwarranted and unexpected access of a user's file data. For instance, imagine some extension having proper privileges to execute chrome code. If a user dragged code from one side of the desktop to the other side, and passed through the browser window, the chrome caller would be able to detect a drag event and instantiate a DOMFile object and extract a file's contents, all without the user's knowledge. This issue was alleviated by populating the .files attribute of a dataTransfer *only* on a drop event, and not on a dragstart event, making it less likely a user could ever inadvertently give up file data.
**Large files (on the order of multiple 100's of MB) are a bit of a predicament. If a user decides to pass them in for whatever inane reason, the browser stalls as it tries in vain to access all the data, only to receive malloc failure after malloc failure ad nauseum. Of course, the stalling time is somewhat alleviated by the cancelReads functionality, but the malloc failure unfortunately isn't. Not really certain what security threat this shortcoming could pose, but it does seem like malicious things could arise from it.
**Large files (on the order of several 100's of MB) are a bit of a predicament. If a user decides to pass them in for whatever inane reason, the browser stalls as it tries in vain to store all the data in memory, only to receive malloc failure after malloc failure ad nauseum. Of course, the stalling time is somewhat alleviated by the cancelReads functionality, but the malloc failure unfortunately isn't. Not really certain what security threat this shortcoming could pose, but it does seem like malicious things could arise from it.
**CancelReads makes me suspicious, in that I have an inkling (i.e. without any demonstrable evidence) that some specific ordering of getFileContent() and cancelReads() calls can mess up memory management. This is only a suspicion, admittedly, but I do want to scrutinize this function as extensively as possible.
**CancelReads makes me suspicious, in that I have an inkling (i.e. without any demonstrable evidence) that some specific ordering of getFileContent() and cancelReads() calls can mess up memory management. This is only a suspicion, admittedly, but I do want to scrutinize this function as extensively as possible.


Matin
10

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/160895"

Navigation menu