Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

latest IE, Chrome, Opera and Firefox and they all render the innermost frame. (don't have a Safari instance handy at the moment to test but welcome others' reports) -Brad ________ From: Hill, Brad Sent: Friday, August 16, 2013 4:44 PM To: Richard Barnes

Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

Additional comments inline. (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment";? [Hill, Brad] Agreed

Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of Tobias Gondrom Sent: Wednesday, August 14, 2013 9:42 AM To: barryle...@computer.org; turn...@ieca.com Cc: draft-ietf-websec-x-frame-opti...@tools.ietf.org; websec@ietf.org; i...@ietf.org; websec-cha...@tools.ietf.org Sub

[websec] X-Frame-Options EBNF bug at Mozilla

This bug at Mozilla was recently brought to my attention: https://bugzilla.mozilla.org/show_bug.cgi?id=836132 It seems to indicate that the specified EBNF of using a colon between "ALLOW-FROM" and the URI is not the actual behavior of most user agents that implement that functionality. Perhaps

[websec] Call for Consensus: CORS to Candidate Recommendation

WebApps and WebAppSec WG members, (and copied security interest groups who we invite to provide comments) Following discussion at TPAC, I've resolved outstanding changes in the security considerations section agreed to by WebAppSec as well as differences between the W3C and WHATWG versions of C

Re: [websec] WGLC for X-Frame-Options

In "2.3.1. Enable HTML content from other domains", the object tag is mentioned in addition to frame and iframe. This list should also include the applet and embed tags, although user agent behavior may not be consistent on this. In "5. Security Considerations", it should be mentioned that cu

[websec] Call for review of Content Security Policy 1.0

The Web Application Security Working Group at the W3C is planning to advance Content Security Policy 1.0 to Candidate Recommendation - a final set of features and syntax - and is seeking wide review of the document at this time. We would especially value the input of members of the IETF WebSec

Re: [websec] handling STS header field extendability

ed) script from non-EV > paypalobjects.com. If you distinguish EV paypal.com and non-EV paypal.com > as distinct origins, it doesn't help anything if either origin explicitly > includes > script from any other origin (of any security level). [Hill, Brad] No apology needed. https:/

Re: [websec] handling STS header field extendability

There are, of course, non-browser HTTP clients that may respect HSTS, but EV certificates in particular are aimed at a browser audience as it is about user trust indicators. EV is *not* a security boundary in browsers, however. It is a brand awareness and consumer trust product. I am not awa

Re: [websec] Websec WG meeting in Vancouver July-31 - submit agenda topics until July-21?

Sounds excellent. Thanks for the time. > -Original Message- > From: Tobias Gondrom [mailto:tobias.gond...@gondrom.org] > Sent: Wednesday, July 18, 2012 9:23 AM > To: Hill, Brad > Cc: alexey.melni...@isode.com; websec@ietf.org > Subject: Re: [websec] Websec WG meeting in

Re: [websec] Websec WG meeting in Vancouver July-31 - submit agenda topics until July-21?

Yes, this is the CSP vs. frame-options discussion - sorry to be oblique. > -Original Message- > From: Alexey Melnikov [mailto:alexey.melni...@isode.com] > Sent: Wednesday, July 18, 2012 3:33 AM > To: Hill, Brad > Cc: Tobias Gondrom; websec@ietf.org > Subject: Re:

Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

Dave, What's the case for the "NoAncestors" behavior? Is it just a performance optimization? I'm a little bit concerned that walking the full ancestors stack is going to become quite important as more sites start using constructs like seamless, sandboxed iframes to display untrusted content

Re: [websec] Websec WG meeting in Vancouver July-31 - submit agenda topics until July-21?

Tobias, I'd like to ask for some time on the agenda to discuss the future policy conveyance for framing/embedding options for HTTP resources. EKR and JeffH will be in Vancouver from the WebAppSec WG and I will be participating remotely. Thanks, Brad Hill W3C WebAppSec WG co-chair > -Ori

[websec] Frame-Options Rosetta Stone (also: frame-ancestors, embed-ancestors)

To add some context to the Frame-Options and CSP UI Safety directives discussion, here's my summary of the current and historical proposals: HTML-based web applications can embed or "frame" other web applications. Unfortunately, if done in an unrestricted fashion, this can lead to various atta

[websec] Last Call for Comments at W3C: Content Security Policy 1.0

The WebAppSec WG at the W3C would like to inform WebSec that Content Security Policy (CSP) 1.0 has been published as a Last Call Working Draft, and the WG welcomes review, feedback and comments to public-webapp...@w3.org CSP is a mechanism web applications can u

Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

Tobias, I'm happy to move the discussion primarily to websec, and I'll drop the cc: to webappsec after this email. Thanks for the historical clarification, as well. I'm not terribly concerned about which group does the work, as much as arriving at the engineering solution that works best for

[websec] Coordinating Frame-Options and CSP UI Safety directives

Tobias, David and other WebSec participants, Over at the W3C WebAppSec WG we are beginning to draft a set of new directives for Content Security Policy focused specifically on User Interface Safety - protection against clickjacking and other UI Redressing attacks. As Adam Barth suggested on t

Re: [websec] X-Frame-Options and SSL

STS require https-only framing, alice.com is left with only bad choices: bear the risk of clickjacking, turn off HSTS, or don't partner and forgo the revenue from example.com. -Brad -Original Message- From: Devdatta Akhawe [mailto:dev.akh...@gmail.com] Sent: Friday, July 22, 20

Re: [websec] X-Frame-Options and SSL

amed by the insecure bob.com because the risk/fraud rates from only active attackers may be acceptable or amenable to other compensating controls, where those from generalized remote clickjacking may not. Brad -Original Message- From: Devdatta Akhawe [mailto:dev.akh...@gmail.com] Sent: Frid

Re: [websec] X-Frame-Options and SSL

Devdatta is correct that allowing an insecure page to frame a secure one, even with permission, presents a clickjacking risk in the presence of an active network attacker. Not to gratuitously muddy the waters, but I'm of two minds about the proposed measure: 1) Don't add the invariant, because

Re: [websec] Frame embedding: One problem, three possible specs?

rom-Origin, the WebAppSec WG is already chartered to do the necessary coordination. -Brad -Original Message- From: Adam Barth [mailto:w...@adambarth.com] Sent: Thursday, July 07, 2011 3:24 PM To: Thomas Roessler Cc: Tobias Gondrom; Arthur Barstow; Hill, Brad; Eric Rescorla; Alexey Melnikov