On Mon, Oct 02, 2017 at 11:13:20AM -0400, Boris Zbarsky wrote:
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...
OK, I'll try a talos run with [NeedsCallerPrincipal] added to
setAttribute and see where that comes out. If it looks good,
I'll investigate that route some more. Otherwise, I'll probably
go with a JSContext wrapper and retrieve the principal on
demand.
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...
Making it not work with document.write() is probably acceptable,
but I don't think we'll be able to get away with not supporting
innerHTML and friends.
This is why I wanted to go with an activation record approach
for the parser case, though. It should be easy enough for the
parser to handle removing the activation record when parsing is
interrupted or scripts are unblocked, and restoring it when it
resumes.
We may even be able to store the same type of context object
we'd use for setAttribute in it, and have the parser pass that
along to SetAttr calls.
I wonder whether we can coordinate with the Chrome folks somehow to
make sure that this stuff works in the same set of cases.
This is always a touchy subject. So far, they've been unwilling
to publicly participate in standardizing anything related to
their extension APIs.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
