Closed Bug 265901 Opened 20 years ago Closed 20 years ago

Make document() pay attention to content policies

Categories

(Core :: XSLT, defect)

Product:
Core
Component:
XSLT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: sicking, Assigned: sicking)

Details

Spinoff from bug 203211. Check with content-policies when loading
document()-loaded documents.

One question is what to do when we encounter a document that should not be
loaded. Should we abort the stylesheet by returning an error, or should we act
like the document didn't exist and return an empty nodeset?
The spec says that we may signal an error, and if we don't we should return an
empty nodeset. In most other cases where we're allowed to recover we've chosen
to do that so I think it would make sense to do that here too. However putting a
warning in the js-console might be a good idea.
Sicking, where are these loads started, exactly?  Do we do a security check for
them now?
It starts in txParseDocumentFromURI:

http://lxr.mozilla.org/mozilla/source/extensions/transformiix/source/xml/parser/txXMLParser.cpp#86

Erm, i was pretty sure that we had same-origins checks, but I can't seem to find
them. If we don't have them that would be a pretty bad security problem.
ah, phew, we do have sameorigins checks further down the callchain, the
syncloader checks for sameorigin in nsSyncLoader::LoadDocument:

http://lxr.mozilla.org/mozilla/source/content/base/src/nsSyncLoadService.cpp#329
Hmm... I guess we could do a content-policy check in syncloader... Or should we
do it higher up the chain somewhere?
I'm not entierly sure when we're supposed to use content-policies as opposed to
just same-origin checks?
Well, they're pretty entirely different things.  Same-origin checks are a
security feature.  Content policies are an extensibility feature (allowing
embeddors to drop in filters of various sorts and whatnot).

So a security check just cares about who's loading what URI, whereas content
policy, in general, cares about the circumstances of the load (what sort of
thing is being loaded, what exact document triggered the load, etc).

It seems to me that putting the content policy check in the syncloader would not
give content policy implementors much in the way of information, since the
syncloader simply doesn't have the extra data that content policy wants.

Also, I'm not sure we want to burden all syncloader callers with content policy
stuff... but I'm also not sure who the callers are.
Yeah, then the syncloader defenetly isn't the right place, i think there's a few
internal callers for things like xbl that uses it and there's no reason to check
those requests against contentpolicies.

All in all i'm not at all sure we need this bug at all. I'd say that we should
do the same as we do for document.load, if we check policies there we probably
should here too.
I don't believe document.load does a content policy check right now, no.
Well, lets close this baby then :)

Feel free to reopen if anyone thinks we should check with contentpolicies here,
or if we add it to document.load
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.