Open Bug 1355055 Opened 7 years ago Updated 2 years ago

Replace using SEC_FORCE_INHERIT_PRINCIPAL within docshell with something better

Categories

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

enhancement

Tracking

()

People

(Reporter: ckerschb, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-backlog1])

Even though Bug 1353975 fixes the problem described in that bug we should think of replacing SEC_FORCE_INHERIT_PRINCIPAL within docshell with something better.
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
I suspect that this is a lot more important than "backlog", given that this has already led to one security bug...  The FORCE_INHERIT_PRINCIPAL thing is just not very compatible with how other parts of the system are trying to use loadinfo.
Assignee: nobody → ckerschb
Status: NEW → ASSIGNED
Priority: P3 → P2
Whiteboard: [domsecurity-backlog1] → [domsecurity-active]
(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #1)
> I suspect that this is a lot more important than "backlog", given that this
> has already led to one security bug...  The FORCE_INHERIT_PRINCIPAL thing is
> just not very compatible with how other parts of the system are trying to
> use loadinfo.

Boris, I think this bug is next on my todo list, but I am not sure what you have in mind. If you could provide some pointers then I am happy to implement and also to provide some more debug information (if needed) to move this bug forward.
Flags: needinfo?(bzbarsky)
I don't have something specific in mind here so far; things need to be designed.

What I do have are several problem identifications:

1) The SEC_FORCE_INHERIT_PRINCIPAL flag as used by docshell is based on the initial URI being loaded.  But then it's propagated along when redirects happen.  That's bogus.  The only saving grace is that the cases that currently set SEC_FORCE_INHERIT_PRINCIPAL in docshell can't cause redirects.  I think.

2) The SEC_FORCE_INHERIT_PRINCIPAL flag is not stored in session history, and is recomputed dynamically when a load starts.  But it affects the interpretation of the principalToInherit part of the loadinfo, which _is_ stored in session history.  This means session history generally can't correctly replay a load, as far as I can tell.  It's not an issue for loads docshell itself starts, again because in that case it would consistently set SEC_FORCE_INHERIT_PRINCIPAL.  But it's a problem for redirects.

Given all that, I think the only reasonable thing to do is to have SEC_FORCE_INHERIT_PRINCIPAL to mean "I know I want this load to inherit the principalToInherit, no matter whether it gets redirected in the future or not or where the information for this load comes from".  That's the use in things like XHR, for example.  Of course in that situation we could also just explicitly set something that forces the principal on the load.  I don't know whether it's better to use the combination of SEC_FORCE_INHERIT_PRINCIPAL and principalToInherit or some other mechanism for this.

With that premise, we need to evaluate all consumers of SEC_FORCE_INHERIT_PRINCIPAL to see whether those are the semantics they want.  For docshell and I expect nsObjectLoadingContent they clearly are not.

Then for the consumers that want different semantics, we need to figure out what semantics they want and how to represent them in loadinfo, ideally in a way that is persisted in session history.
Flags: needinfo?(bzbarsky)
Assignee: ckerschb → jkt
Priority: P2 → P3
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]
Assignee: jonathan → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.