javascript: URIs

[Boris Zbarsky]

I've been thinking recently about javascript: URIs, and I think we need to make
a fundamental change in the way we handle them.

Right now, the way javascript: URIs work is the following:

1) Most javascript: URIs don't get a channel owner principal.
2) javascript: URIs loaded in a docshell (main window or
subframe) get a channel owner principal.
3) javascript: URIs without a channel owner principal
are executed in a sandbox.
4) javascript: URIs with a principal are executed in a
sandbox if the principal doesn't match that of the page
they're being executed against. Otherwise they're executed
in the page's script context.

The problem is that javascript: is not the only thing that cares about the owner
principal, and right now we're having to pass a null principal in various places
because we don't want scripts there to execute against the page's context. The
reason we don't want that is that sites don't do the best fitlering of
user-supplied content, and we don't want a CSS "background:
url('javascript:...');" to touch the page's data on myspace or some such (e.g.
we don't want it to be able to get cookies).

I propose that we separate out the issue of user-supplied content from the issue
of security by making javascript: URIs not execute by default. For them to
execute, in this model, someone needs to make a note on the javascript: URI that
it should execute. Docshell could do this for URIs loaded in docshell, for
example. Then we can pass in an owner in a lot more places (image loads, URI
loads from CSS, etc).

This way, we can effectively whitelist as allowed to execute only those cases
which are well-known to the web authoring community as needing to be filtered.
I suspect that these are basically just the docshell cases, especially with IE7
apparently either not executing javascript: in <img> srcs or executing it in a
sandbox (kinda hard to tell which from over here).

So the proposed model I have is the following:

1) All URI loads, ideally, have the right owner principal set.
2) javascript: URIs that are not explicitly marked otherwise
do not execute.
3) javascript: URIs which are marked to execute but do not have a
channel owner principal do not execute (and assert, because
this should really not happen).
4) javascript: URIs with a principal are executed in a sandbox if the
principal doesn't match that of the page they're being executed against.
Otherwise they're executed in the page's script context.

We may want to put the flag on the channel instead of the URI, or on both,
depending on what callers have. That's an implementation detail, as far as this
proposal is concerned.

Thoughts?

-Boris

P.S. I realize we'd need to wontfix bug 355365 if we do this. Frankly, I'm
cool with that. That's what data: URIs are for; if our <img> support actually
obeyed content-type headers the pnglets thing wouldn't work anyway.

[brenda...@gmail.com]

I've urged over and over to separate the literally unfixable problem of
protecting sites such as MySpace and LiveJournal from improperly
sanitized or sandboxed user-generated content, and us fixing our own
codebase to track javascript: subject principals. So I'm good with
making progress, even if it requires brute-force to classify cases that
should not work as they did in Netscape 2-4.

Breaking pnglets or doodlepad
(https://bugzilla.mozilla.org/show_bug.cgi?id=148967), on the other
hand, with the claim that such sites should use data: anyway, seems
wrong to me. Those techniques pre-date data: being supported well or
at all. If it were the case that, with correct propagation of
principals through all URI load paths where the URI could be
javascript:, pnglets and the doodlepad would "just work", why should we
break them?

The web platform components being used here are over ten years old, but
that doesn't mean "time to change". It could mean "leave working" or
"still important". If our principals tracking is sound, we should
maximize cases that work, not look for cases to break by brute-force
checks, with our message being "change your content".

/be

[Boris Zbarsky]

brenda...@gmail.com wrote:
> Breaking pnglets or doodlepad
> (https://bugzilla.mozilla.org/show_bug.cgi?id=148967), on the other
> hand, with the claim that such sites should use data: anyway, seems
> wrong to me. Those techniques pre-date data: being supported well or
> at all. If it were the case that, with correct propagation of
> principals through all URI load paths where the URI could be
> javascript:, pnglets and the doodlepad would "just work", why should we
> break them?

Well. If web authors know to filter that stuff, we shouldn't break them. If
they don't we imo should.

Note that once we implement my proposal this decision will just be one of
whether <img> element image loads should set this flag on the URI, since we
_will_ in fact propagate the principal.

The main point of my proposal is that we should move from the current situation
of no principal tracking to principal tracking with a whitelist of what
javascript: URIs execute. Then we determine the exact contents of that
whitelist. I think it needs to be a whitelist because we want to add features
without causing grief for sites that have user-provided content.

So if the basic idea makes sense, let's do it. Then we can argue about what we
whitelist. ;)

-Boris