search

w3c / webappsec-secure-contexts

WebAppSec Secure Contexts
https://w3c.github.io/webappsec-secure-contexts/
Other
33 stars 28 forks source link

Should secure iframes of insecure parents be considered secure? Spec is self-contradictory. #54

Closed bzbarsky closed 6 years ago

bzbarsky commented 6 years ago

https://github.com/w3c/webappsec-secure-contexts/commit/98f2c2634f7371bca6ffacbf73e984b22af521ab removed the check for a creator browsing context, which affects not only opener bits but subframes.

At this point, https://w3c.github.io/webappsec-secure-contexts/#is-settings-object-contextually-secure says that a secure subframe of an insecure parent is secure, while https://w3c.github.io/webappsec-secure-contexts/#examples-framed claims it shouldn't be.

Mixed content blocking doesn't really help, even if it were always on; consider http://example.com framing http://localhost (allowed by mixed-content blocking); is that subframe a secure context?

ccing folks from https://github.com/w3c/webappsec-secure-contexts/issues/42: @mikewest @jakearchibald @annevk @travisleithead @jwatt @mnoorenberghe

travisleithead commented 6 years ago

Interesting. The example seems to make the most sense--that an insecure parent can never host a secure iframe. I don't suppose 98f2c26 intentionally broke this...

bzbarsky commented 6 years ago

I expect it was unintentional: the same check for creator context was handling parents and window.open bits...

mikewest commented 6 years ago

Indeed, that was a mistake on my part. I'll fix it up, thank you!