On Fri, Dec 2, 2016 at 9:07 AM, Michael A. Peters
wrote:
> On 12/02/2016 08:47 AM, Boris Zbarsky wrote:
>>
>> On 12/2/16 11:34 AM, Michael A. Peters wrote:
>>>
>>> It seems that CSP behavior has radically changed since the last time I
>>> looked at it
>>
>>
>> I can't speak to when you last looked
On 12/02/2016 08:47 AM, Boris Zbarsky wrote:
On 12/2/16 11:34 AM, Michael A. Peters wrote:
It seems that CSP behavior has radically changed since the last time I
looked at it
I can't speak to when you last looked at it, but the current state
shipping in browsers is, as far as I know, no differ
On 12/2/16 11:34 AM, Michael A. Peters wrote:
It seems that CSP behavior has radically changed since the last time I
looked at it
I can't speak to when you last looked at it, but the current state
shipping in browsers is, as far as I know, no different from what
browsers shipped initially for
On 12/02/2016 08:23 AM, Boris Zbarsky wrote:
On 12/2/16 11:01 AM, Michael A. Peters wrote:
Personally I love CSP but it does not allow inline scripts or inline CSS
Only if you say to not allow them. The default behavior allows them.
For example, this disallows inline scripts, because script-s
On 12/2/16 11:23 AM, Boris Zbarsky wrote:
(except for maybe with the new unsafe-inline option that requires
checksum in the head ???)
unsafe-inline doesn't require a checksum. See examples above.
It's also not new. Certainly the November 2012 CR of CSP 1.0 [1] has
unsafe-inline.
-Boris
On 12/2/16 11:01 AM, Michael A. Peters wrote:
Personally I love CSP but it does not allow inline scripts or inline CSS
Only if you say to not allow them. The default behavior allows them.
For example, this disallows inline scripts, because script-src is
explicitly specified without unsafe-in
Personally I love CSP but it does not allow inline scripts or inline CSS
and over 95% of the web makes heavy use of both.
I believe there now are CSP parameters that relax those prohibitions but
from I understand they are only relaxed when a hash of the inline
scripts / CSS is declared in the
Could you elaborate on the point made earlier that CSP is too complicated
to implement? What would the fix for this particularly security hole look
like, using CSP?
On Fri, Dec 2, 2016 at 1:11 AM Richard Maher wrote:
Thanks Michael. So to be safe one should use Edge? Who'd have thunk it?
Anyone
Thanks Michael. So to be safe one should use Edge? Who'd have thunk it?
Anyone tested Michael's example on FireFox or Safari?
It does look like Chrome is the driver of rel=noopener. Does the credential
API https://w3c.github.io/webappsec-credential-management/ rely on this
flaw?
On Fri, Dec 2, 2
If window.opener() did not work cross-domain then as far as I can tell
that would be secure.
On 12/01/2016 07:23 PM, Richard Maher wrote:
I see what you're saying Michael and also agree it's serious. Would I be
correct in thinking that MS Edge solves the problem by not returning
window.opener c
I see what you're saying Michael and also agree it's serious. Would I be
correct in thinking that MS Edge solves the problem by not returning
window.opener cross-domain? Is the UA not a logical and uniform place for
this?
BTW I've also experienced the CitHub topic-closure nazis many times :-(
On
On 12/01/2016 06:14 PM, Elliott Sprehn wrote:
On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky wrote:
On 12/1/16 1:41 AM, Chris Holland wrote:
I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward
Well if it was done as a header, I suppose it could be added as a
http-equiv meta tag for those who want to.
Header is the easiest solution to make sure it is applied everywhere
without question. It could even be added at the front-end proxy to cover
numerous web applications on many domains a
On 12/01/2016 05:39 PM, Domenic Denicola wrote:
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson
I believe that's a bit of an overstatement. There are certainly risks involved
in window.opener (they're briefly discussed in the spec itself), but it doesn't
remove
On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky wrote:
> On 12/1/16 1:41 AM, Chris Holland wrote:
>
>> I think the devil would be in implementation detail. Slapping a
>> "rel/noopener" attribute on a specific link is very deterministic and
>> straightforward from a logic standpoint Whichever
From: Zac Spitzer [mailto:zac.spit...@gmail.com]
> how about rather than requiring this on every why not support a base tag
> directive for the whole document i.e. , similar to
> ?
Yes, this is a good idea to include in a general framework for imposing such
self-restrictions on your page, s
how about rather than requiring this on every why not support a base
tag directive
for the whole document i.e. , similar to ?
On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola wrote:
> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian
> Hickson
>
> > I believe that's a bit
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson
> I believe that's a bit of an overstatement. There are certainly risks
> involved in window.opener (they're briefly discussed in the spec itself), but
> it doesn't remove the origin checks.
This is the crucial point
On 12/1/16 1:41 AM, Chris Holland wrote:
I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward from a logic standpoint Whichever window was created
from this link can't control the parent.
It's
I guess this issue was discussed at the following thread on chromium.org,
with comment #10 offering the more interesting exploit vector that seems to
happen on sites with user-generated content (UGC):
https://bugs.chromium.org/p/chromium/issues/detail?id=168988#c10
... and Comment 11 right after
On 11/30/2016 06:21 PM, Michael A. Peters wrote:
On 11/30/2016 05:23 PM, Ian Hickson wrote:
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters
wrote:
Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.
I believe that's
On 11/30/2016 05:23 PM, Ian Hickson wrote:
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters
wrote:
Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.
I believe that's a bit of an overstatement. There are certainly ris
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters
wrote:
>
> Right now the specification for window.opener() is seriously insecure,
> allowing for cross-domain script access by default.
>
I believe that's a bit of an overstatement. There are certainly risks
involved in window.opener (they're bri
23 matches
Mail list logo
