Re: Using CSP

Generally, including and http iframe in an https page isn't a great idea
because it can be corrupted by an active network attacker (that's why it
triggers mixed content warnings).

Adam
 On Jul 27, 2011 3:44 AM, "Nick Gearls" <nickgearls@gmail.com> wrote:
> Just to clarify: 'self' currently means same server and same protocol.
> It disallows a HTTPS iframe in a HTTP page (good from a security point
> of view).
> It disallows a HTTP iframe in a HTTPS page (that should be allowed).
>
> Regards,
>
> Nick
>
> On 26/7/2011 19:26, Boris Zbarsky wrote:
>> On 7/26/11 1:21 PM, Hill, Brad wrote:
>>>> Again, the context here is that HTTP content is framing HTTPS content
>>>> at the same host
>>>> and the latter wants to use 'self' in allow-frames to allow the
>>>> framing. _That_ is what I
>>>> would like to understand use cases for.
>>>
>>> That's not how I understood it. I think the request was that "self",
>>> in the context of CSP for an HTTP resource, also implicitly include
>>> HTTPS of the same origin.
>>
>> That was sort of the request, yes.
>>
>>> In the context of IFRAMEs this is about loading the framed content
>>> from HTTPS; it is not about the HTTPS resource's declarations of who
>>> might have permission to frame it.
>>
>> The precise quote was:
>>
>> The problem is that if you use, for instance, "frame-src 'self'" to
>> ensure that your pages cannot be framed in another site,
>>
>> I hadn't realized when I read that that the part starting "to ensure"
>> was just completely unrelated to the actual CSP directive used.
>>
>> I can see the argument for allowing linking to an https frame on the
>> same server, I guess. It still feels like something more likely to be
>> used to feel good about security than to actually be secure, but I take
>> your point about incremental movement to https.
>>
>> -Boris
>>
>>
>>
>

Received on Wednesday, 27 July 2011 20:42:16 UTC