Open Bug 1479410 Opened 3 years ago Updated 3 years ago

Evaluate if we can perform CheckLoadURI() checks before we ever call stat()

Categories

(Core :: DOM: Security, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: ckerschb, Unassigned)

Details

(Whiteboard: [domsecurity-backlog1])

Ultimately it would be good to unify our security checks around symlinks making sure we call CheckLoadURI() before we ever state() a file. Ideally we should not state() before the security checks within AsyncOpen2() on a channel are called.

Copying some relevant background information over from a different bug:

> 1)  Some of our security checks (e.g. CheckMayLoad) _require_ that symlinks
> be resolved 
>     before a check is done, due to the fact that we treat files in the same
> dir as same-origin
>     but symlinks can cross directory boundaries.  This obviously requires a
> stat().
> 2)  CheckMayLoad also needs to stat() files because it needs to treat
> file:///foo and file:///FOO
>     as same-origin on case-insensitive filesystems.
> 3)  For this bug, it sounds like CheckLoadURI needs to happen _before_ we
> ever stat() the file.

Ultimately we need to make sure that we never resolve symlinks until after we have performed the CheckLoadURI check.
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #0)
> Ultimately we need to make sure that we never resolve symlinks until after
> we have performed the CheckLoadURI check.

Don't we need to also do another check after resolving symlinks? Esp. for cases where file:///foo and file:///bar try to link to each other (which they're not normally allowed to today).
Flags: needinfo?(ckerschb)
(In reply to :Gijs (he/him) from comment #1)
> (In reply to Christoph Kerschbaumer [:ckerschb] from comment #0)
> > Ultimately we need to make sure that we never resolve symlinks until after
> > we have performed the CheckLoadURI check.
> 
> Don't we need to also do another check after resolving symlinks? Esp. for
> cases where file:///foo and file:///bar try to link to each other (which
> they're not normally allowed to today).

Yes, I would say so.
Flags: needinfo?(ckerschb)
You need to log in before you can comment on or make changes to this bug.