Re: Content Security Policy feedback
Bil Corry wrote: > > I personally see value there for the website, but if 99.9% of websites > will never do anything with the header, then it probably isn't > worthwhile (or it may take version 2 before the need is evident). The > big challenge here is making sure the CSP announcement header can not > be spoofed via XHR, so to that end, I'd recommend prefixing the header > name with "Sec-" such as "Sec-Content-Security-Policy" -- the latest > draft of XHR2 specifies that any header beginning with "Sec-" is not > allowed to be overwritten with setRequestHeader(): > > http://www.w3.org/TR/XMLHttpRequest2/#setrequestheader > > Of course, XHR2 would have to be implemented in the browsers first in > order to take advantage of the requirement. My 2c is that if we do this we should do versioning from the get go, otherwise servers will have a hard time telling CSP v1.0 from CSP unsupported clients in the future. On one hand this may waste some bandwidth now, but then again if it saves the server from sending CSP responses to clients that don't support it, it may actually save bandwidth and simplify server logic (since servers will be able to determine conclusively that CSP is supported, rather than guessing). > > I don't have a specific use case, I'm thinking more of the edge cases > where content is allowed from a domain that allows a multitude of > third-party content. Maybe this is something to explore for v2 if > warranted. > I think part of the challenge is that CSP governs a number of different operations, some of which may be meaningful to restrict to a specific path but others may not be (i.e. scripting vs asset loading). If we had a few specific examples that would help us get our brains around whether or not enforcing restrictions on a per-path basis would actually be a contract that is enforcable. For (a contrived) example, say mashup.com hosts a number of different widgets, but myapp.com wants to restrict loading of iframes from only mashup.com/good. If the user happens to have another app from mashup.com/bad loaded in another window/tab, then in theory content from mashup.com/bad could script directly into the iframe contain mashup.com/good within myapp.com, bypassing the loading restriction. That is probably not the best example, but the root of this problem is that scripting permissions are really still only enforceable on a per fully-qualified domain name basis, regardless of any loading restrictions. > >>> (3) Currently the spec focuses on the "host items" -- has any thought >>> be given to allowing CSP to extend to sites being referenced by "host >>> items"? That is, allowing a site to specify that it can't be embedded >>> on another site via frame or object, etc? I imagine it would be >>> similar to the Access Control for XS-XHR[2]. >> I would agree with Gerv, that this feels a bit out of scope for this >> particular proposal. > > Then maybe something to consider down the road. It would be useful to > prevent hot linking and clickjacking > . I think the primary reason this seems out of scope is that CSP is a mechanism for servers to govern their own content, rather than specifying policies for 3rd party content. The latter seems more like the domain of Access Control. Access Control AFAIK is not intended just for XHR2, so I could image it being extended to govern opt-out of cross-domain content loading, as well as to opt-in. Thank you for your feedback btw, it is much appreciated. Lucas. > > - Bil > ___ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: UniversalBrowserRead CAPS in V2.0.0.18 and 3.0.4
On Nov 21, 3:37 pm, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Sorry, I must be missing something. I have been setting the .src of an > > IFRAME to the cross-domain URL which gives the calling javascript the > > HTML of the target so it can then generate the DOM structure. That is > > what has worked fine with the user_pref settings above. > > > If, instead, I oculd do an XHR GET, that would be preferable. Is that > > the distinction you are looking for? > > > If that is still insufficient for you, please tell me what you are > > looking for that makes a difference in the way the user_prefs should > > now be set. > > I'm looking for the exact function call that's failing (the name, the > object it's a function on), together with a description (ideally > copy/paste) of the exception that's thrown. > > I mean, are you doing parent.userDefinedFunction(window.document)? Are > you doing childFrame.document.innerHTML from the parent frame? > Something else? > > -Boris > > P.S. Please readhttp://www.chiark.greenend.org.uk/~sgtatham/bugs.html? Great paper. I want to refer others to it. I think we have been a little bit on different wavelengths. I presumed that what I was seeing was a common issue that others already had a solution for, and that it was not necessarily a bug. So this is great, we're finally on the same wavelength. To get to your specifics, the approach is the latter of your two above. The specific code is: document.getElementById (IFRAMEnum).contentDocument.documentElement.innerHTML ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: UniversalBrowserRead CAPS in V2.0.0.18 and 3.0.4
[EMAIL PROTECTED] wrote: Sorry, I must be missing something. I have been setting the .src of an IFRAME to the cross-domain URL which gives the calling javascript the HTML of the target so it can then generate the DOM structure. That is what has worked fine with the user_pref settings above. If, instead, I oculd do an XHR GET, that would be preferable. Is that the distinction you are looking for? If that is still insufficient for you, please tell me what you are looking for that makes a difference in the way the user_prefs should now be set. I'm looking for the exact function call that's failing (the name, the object it's a function on), together with a description (ideally copy/paste) of the exception that's thrown. I mean, are you doing parent.userDefinedFunction(window.document)? Are you doing childFrame.document.innerHTML from the parent frame? Something else? -Boris P.S. Please read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html ? ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: UniversalBrowserRead CAPS in V2.0.0.18 and 3.0.4
On Nov 20, 8:38 pm, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > These have been sufficient in the past to allow cross-domain reads > > during development prior to plugin development. UniversalBrowserWrite > > was actually only a convenience for processing some style information > > and is actually not critical. > > Sure. I'm just saying that depending on exactly how you're doing your > "cross-domain reads" they might no longer be sufficient. It's really > hard to say anything else given the information you're willing to provide. > > -Boris Sorry, I must be missing something. I have been setting the .src of an IFRAME to the cross-domain URL which gives the calling javascript the HTML of the target so it can then generate the DOM structure. That is what has worked fine with the user_pref settings above. If, instead, I oculd do an XHR GET, that would be preferable. Is that the distinction you are looking for? If that is still insufficient for you, please tell me what you are looking for that makes a difference in the way the user_prefs should now be set. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy feedback
On Nov 20, 4:37 pm, bsterne <[EMAIL PROTECTED]> wrote: > On Nov 17, 2:19 pm, Bil Corry <[EMAIL PROTECTED]> wrote: > > > (1) Something that appears to be missing from the spec is a way for > > the browser to advertise to the server that it will support Content > > Security Policy, possibly with the CSP version. By having the browser > > send an additional header, it allows the server to make decisions > > about the browser, such as limiting access to certain resources, > > denying access, redirecting to an alternate site that tries to > > mitigate using other techniques, etc. Without the browser advertising > > if it will follow the CSP directives, one would have to test for > > browser compliance, much like how tests are done now for cookie and > > JavaScript support (maybe that isn't a bad thing?). > > This isn't a bad idea, as I have seen this sort of "compatibility > level" used successfully elsewhere. If future changes are made to the > model which would define restrictions for new types of content (e.g. > ), or which would affect the default behaviors for how content > is allowed to load, then it will be useful to servers to have their > clients' CSP version information. If we are going to add this to the > model, then we should do so from the beginning to avoid the > potentially messy browser compliance testing that would result after > the first set of changes. I personally see value there for the website, but if 99.9% of websites will never do anything with the header, then it probably isn't worthwhile (or it may take version 2 before the need is evident). The big challenge here is making sure the CSP announcement header can not be spoofed via XHR, so to that end, I'd recommend prefixing the header name with "Sec-" such as "Sec-Content-Security-Policy" -- the latest draft of XHR2 specifies that any header beginning with "Sec-" is not allowed to be overwritten with setRequestHeader(): http://www.w3.org/TR/XMLHttpRequest2/#setrequestheader Of course, XHR2 would have to be implemented in the browsers first in order to take advantage of the requirement. > > (2) Currently the spec allows/denies based on the host name, it might > > be worthwhile to allow limiting it to a specific path as well. For > > example, say you use Google's custom search engine, one way to > > implement it is to use a script that sits > > onwww.google.com(e.g.http://www.google.com/coop/cse/brand?form=cse-search-box〈=en). > > By having an allowed path, you could prevent loading other scripts > > from thewww.google.comdomain. > > I don't have a strong opinion on this one. My initial reaction is > that it adds complexity to the model, but perhaps complexity that's > warranted if people feel it's a useful feature. Do you have some > specific use cases to share which would demonstrate the usefulness of > your suggestion? I don't have a specific use case, I'm thinking more of the edge cases where content is allowed from a domain that allows a multitude of third-party content. Maybe this is something to explore for v2 if warranted. > > (3) Currently the spec focuses on the "host items" -- has any thought > > be given to allowing CSP to extend to sites being referenced by "host > > items"? That is, allowing a site to specify that it can't be embedded > > on another site via frame or object, etc? I imagine it would be > > similar to the Access Control for XS-XHR[2]. > > I would agree with Gerv, that this feels a bit out of scope for this > particular proposal. Then maybe something to consider down the road. It would be useful to prevent hot linking and clickjacking . - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
