1205866 - Make it easy to determine the security context of a principal

Status: RESOLVED DUPLICATE of bug 1162772

(Core :: Security: CAPS, defect)

Description

[Richard Barnes [:rbarnes]]

There is an increasing move to limit APIs to "secure contexts".  The "principal" is the unit of context that we have inside gecko, so we should add some API surface that can be used to tell whether the principal represents a secure context or not.  That will help avoid a repeat of the fiasco in Bug 1205156.

It seems like there are two things that might be worth adding to nsIPrincipal:

1. A boolean "isSecure()" or "attribute bool secure" - Determine whether the context is secure according to the secure contexts spec (a.k.a. powerful features)

2. An enum-valued security category, which would basically be the scheme of the origin  ("http", "https", "file", "app") plus a few others ("privileged", "localhost").

Comment 1

[Martin Thomson [:mt:]]

Adding a secure property (or getter) to nsIPrincipal won't tell you if the context is secure according to the spec because you have to look at the global (and its frame ancestors) in order to make that determination.  Also, making this assessment for a worker is hard (see issue raised by Anne).

I would suggest that we stage this:
1. implement something on the principal
2. implement a limited fix on globals: on window do the frame walk; on dedicated workers, call back to the owning window; on shared workers, do the easy thing and only check the principal; on service workers, assume secure == true
3. wait for the spec to stabilize regarding workers and follow

Ideally this is exposed on something that the WebIDL bindings can use.  Because the next bug is likely to be a WebIDL attribute [SecureOnly] that controls exposure.

Comment 2

[Jonathan Watt [:jwatt]]

(In reply to Martin Thomson [:mt:] from comment #1)
> the next bug is likely to be a WebIDL attribute [SecureOnly] that
> controls exposure.

Actually that bug predates this one: bug 1177957.

Comment 3

[Martin Thomson [:mt:]]

The spec has been updated to deal with the workers case.  This suggests that the right approach here is to flag insecure contexts with origin attributes.  There is probably some follow-on work for the shared workers case.

Comment 4

[Jonathan Watt [:jwatt]]

I'd suggest dup'ing this to bug 1162772, and possibly opening new bugs for outstanding issues.

Comment 5

[Mathew Hodson]

Window.isSecureContext was implemented in bug 1162772, which is waht is mentioned in the linked https://w3c.github.io/webappsec-secure-contexts/