Hi there,
here's my feedback from the HTTP/editorial point of view:
Abstract
To improve the protection of web applications against Clickjacking
this standard defines an http response header that declares a policy
s/standard/specification/
s/http response header/HTTP response header field/
communicated from a host to the client browser on whether the browser
must not display the transmitted content in frames of other web
pages. This drafts serves to document the existing use and
drafts?
In 2009 and 2010 many browser vendors ([Microsoft-X-Frame-Options],
[CLICK-DEFENSE-BLOG], [Mozilla-X-Frame-Options]) introduced the use
of a non-standard http header RFC 2616 [RFC2616] "X-Frame-Options" to
s/http header RFC 2616 [RFC2616]/HTTP [RFC2616] header field/
protect against Clickjacking [Clickjacking]. This draft is to
document the current use of X-Frame-Options header and shall in the
future be replaced by the Frame-Options [FRAME-OPTIONS] standard.
What's supposed to be replaced is the header field, not the spec, right?
2. X-Frame-Options Header
The X-Frame-Options HTTP response header indicates a policy whether a
s/header/header field/ throughout.
browser MUST NOT allow to render a page in a <frame> or <iframe> .
whitespace...
2.1. Syntax
The header field name is:
X-Frame-Options
There are three different values for the header field. These values
are exclusive, that is NOT more than one of the three values MUST be
set.
maybe "exactly one"?
DENY
A browser receiving content with this header MUST NOT display
this content in any frame.
SAMEORIGIN
A browser receiving content with this header MUST NOT display
this content in any frame from a page of different origin than
the content itself.
Reference ORIGIN spec?
ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin)
A browser receiving content with this header MUST NOT display
this content in a frame from any page with a top-level browsing
contex of different origin than the specified origin. While
this can expose the page to risks by the trusted origin, in
some cases it may be necessary to allow the framing by content
from other domains.
For example: X-FRAME-OPTIONS: ALLOW-FROM:
https://www.domain.com/
The example needs reformatting.
The ALLOW-FROM URI MUST be valid.
Any data beyond the domain address (i.e. any data after the "/"
separator) is to be ignored. And the algorithm to compare origins
authority component?
from [RFC6454] SHOULD be used to verify a referring page is of the
same origin as the content or that the referring page's origin is
identical with the ALLOW-FROM URI.
Wildcards or lists to declare multiple domains in one ALLOW-FROM
statement are not permitted.
Please note that in conflict with [RFC6454], current implementations
do not consider the port as a defining component of the origin.
2.2. Backus-Naur Form (BNF)
The RFC 822 [RFC0822] EBNF of the X-Frame-Options header is:
X-Frame-Options = "Frame-Options" ":" "DENY"/ "SAMEORIGIN" /
("ALLOW-FROM" ":" URI)
That should reference HTTPbis P1, and just define the field *value, such as:
X-Frame-Options = "DENY"
/ "SAMEORIGIN"
/ ( "ALLOW-FROM" OWS ":" OWS URI )
OWS = <HTTPbis P1 ref>
URI = <RFC3986 ref>
Note that this makes the keywords case-insensitive; if this is intended
it might make sense to call it out. Otherwise, the ABNF needs to be fixed.
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
I'm pretty sure you need normative references for HTTP, ABNF and URI.
> ...
Best regards, Julian
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
