On 9/30/17 12:19 AM, Kris Maglione wrote:
I still haven't settled on the details, but I it will probably have to
involve capturing the caller principal from SetAttr hooks. Which would
involve either changing that machinery to pass along a JS context when
invoked by a scripted caller, or using something like
SubjectPrincipal(). I'd definitely like to hear opinions on the best
approach here.
I'd really rather we didn't use SubjectPrincipal() here. It's too hard
to reason about, and we have better options.
Passing along a JSContext would work. We could have something like
"null means no scripted caller, otherwise caller's compartment is the
part that matters". This relies on no one on the setattr path messing
with the compartment, but that shouldn't be too hard to ensure,
especially since we only have a few attributes on a few elements for
which this is relevant...
I'd love it if we could pass along something that couldn't be
abused/misused like a JSContext. We could make up a wrapper class, but
no matter what we do we'd have the fundamental tradeoff that either we
grab the principal eagerly, and pay the cost for all the cases where it
doesn't matter, or we grab it lazily and run the risk of thing changing
under us. We should probably measure how expensive setAttribute is and
how expensive grabbing the principal from a JSContext (e.g. by marking
the method as [NeedsCallerPrincipal]) is...
The question of how to handler parser-generated nodes is tougher. Just
using SubjectPrincipal() is one obvious approach, but the security
characteristics of that worry me (what if the parser gets invoked by
system code while some JS caller is blocked?).
Yes, that is the fundamental problem with SubjectPrincipal().
But even worse, depending on what you're trying to solve, using
SubjectPrincipal() from SetAttr() doesn't even work right. Consider
this case:
document.write("<script src=foo></script><img src=bar>");
The SetAttr call for the <img> happens async, after the <script>
finishes loading. So the principal state needs to be stored in the
parser itself or something.
Of course the other option is to not make this work for document.write...
I wonder whether we can coordinate with the Chrome folks somehow to make
sure that this stuff works in the same set of cases.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
