Hi Eric, Gerv... thanks for getting this thread started. My replies are
inline due to the diverse range of discussions going on in this thread.
:) I also cut some stuff not relevant to my responses out to shrink
the size of this message.
On 7/6/09 7:46 AM, EricLaw wrote:
On Jul 6, 3:02 am, Gervase Markham <[email protected]> wrote:
On 06/07/09 01:28, EricLaw wrote:> Server CSP Versioning
frame-ancestors
In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT
tags that point to HTML pages, correct?
I guess so :-)
Right. The goal with frame-ancestors is to be able to specify what
sites can embed a protected page in any sort of framing context, no
matter the tag. If an HTML/XHTML/etc document has a CSP, then any
ancestor frame or embedding entity is verified against the policy. So I
guess if a protected HTML document is embedded using OBJECT, then
whatever content set the OBJECT tag must be checked.
The only time this really gets broken is when plug-ins are involved. For
example, there's nothing (short of Flash implementation that supports
CSP) to stop a .swf called via <OBJECT> from loading an HTML page with a
CSP set and rendering it as a subframe.
Are relative URIs valid for the report-URI/policy-URI? (Seems like
this would be a good thing to support). However, if so, is there any
interaction/relationship with the BASE tag, which is supposed to also
appear early in the head?
Very good question.
I believe this is an implementation issue... a relative URI eventually
gets turned into an absolute URI before being requested. It is at that
point (when it has been 'absolutified' or whatever I should call it)
when CSP checks are done. Whether or not a BASE tag is present, the UA
has to figure out what host to request the content from and over what
scheme and port to request it; at this level, relative and absolute URIs
should appear the same. I'll try to make this more obvious in the Spec.
Doesn’t make sense to me, because “self” is defined to include the
scheme. This suggests that we need a "selfhost" directive, which
includes the hostname only.
Or we make the same word serve two purposes, doing the "obvious" thing.
I worry about a changed meaning of the keyword based on context, because
that can lead to bugs. :) Fears aside, using self in the host position
with any additional information (scheme://self or self:port) isn't such
a bad idea, and makes sense to me.
If the “Fail closed” model is used, is there any way for the user to
know why the site is broken? Isn’t this going to create a problem,
where, say, a FF4 user will “downgrade” to a browser that doesn’t
support CSP (say, Opera 9) because the site “works properly there”?
Everyone loses.
This is a problem with a "tighten when the header is used, and then use
directives to loosen" approach. Content Restrictions had the opposite
approach - it started with loose (i.e. the situation as it is without CR
support) and tightened using directives. This avoided this problem. Of
course, both directions have pros and cons.
Oh, I think Fail Closed is a fine model, but unless there's some way
for the user to know why the page is completely busted, it seems
likely that they're going to blame the properly-behaving UA rather
than the site. Pretty much the same problem one encounters with
strict XHTML validation failure-- how do you ensure that the user
blames the site, not the UA?
The spec states that we put errors in the error/debug console (so an
advanced user can see exactly what's going on. Maybe we need to figure
out a "CSP Broken" icon to pop up next to the lock icon in the status
bar? I hate to clutter up the UI unless
Agreeing with Sacolcor, I think the spec should explicitly note that
CSP isn’t intended to apply to User-Scripts, although I think the
Greasemonkey guys might find it hard to implement their current
feature-set considering where CSP is likely to be implemented in the
browser stacks.
We need to avoid breaking Greasemonkey/GreasemonkIE.
I wholeheartedly agree.
I think there's a very
legitimate case to be made for the potential security value in
preventing unexpected cross-domain data reads.
I agree with this, but I subscribe to the "UA provided context for HTTP
requests" school of thought. I think the UA should provide some info
about where requests came from to the server (render context like
stylesheet or image, and source origin) -- then the Server can decide
whether or not to serve the content.
Cheers,
Sid
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
