On Tue, 18 Aug 2009 15:25:35 -0400, Adam Barth <[email protected]> wrote:
On Tue, Aug 18, 2009 at 10:30 AM, Michael A. Puls
II<[email protected]> wrote:
However, 3 out of the 4 main browsers support it. Behavior and security
could be aligned and improved.
We should tread carefully here. The security model for file URLs
isn't fully developed yet.
Yes, of course.
For example:
1. Don't allow access to file: files from a non-file: origin.
2. "file://localhost/" and "file:///" are equivalent. (Browsers convert
to
the one they support.)
3. file://bark/path and file://meow/path are different origins.
It's unclear whether supporting these kinds of URLs is worth the
security issues. Keep in mind that getting this to work properly
involves the cooperation of plug-in vendors.
By 'supporting', you mean in XHR, right? They're already supported in
browsers for everything else.
I believe it's better to expose file: than platform paths that are
different with each platform.
4. Accessing a non-file: origin resource from a file: origin can be
allowed
(like it is in Safari), at least as a non-default option.
This is a poor security choice. The major browsers have been slowly
moving away from the model where file URLs can access web URLs. I
suspect Safari may remove this ability in the future.
Yes, it's probably better left as a non-default, advanced user option.
5. Make file:///c:/ and file:///d:/ different origins if necessary, so
access isn't allowed across drive boundaries. More specifically, only
allow
file:///c:/dir/test.html to access files in file:///c:/dir/ and
sub-directories of file:///c:/dir/. I think Firefox does something like
this.
Firefox has the most innovative security model for file URLs. What
they do is much more subtle than what you describe above. Hopefully
their model will spread to other implementations. However, this
doesn't seem like the right forum to push that agenda at this time.
Where do you suggest then?
I'm not making light of security, but I believe it can be done. Any
additional rules that are agreed upon should improve file:// security in
browsers, not make it worse.
Your suggestions are a mix of security improvements and
disimprovements.
What part is the disimprovement? The Safari case?
Note: I posted this suggestion to see if anyone thought it was a good
idea. If not, I'll try to come up with something better. Or, are you
saying that no matter what I come up with, if it deals with file:, it's a
no-go?
Thanks
--
Michael
