One document matched: draft-gondrom-frame-options-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC822 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0822.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC3864 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3864.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-gondrom-frame-options-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Frame-Options">HTTP Header Frame Options</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="David Ross" initials="D."
surname="Ross">
<organization>Microsoft</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>U.S.</country>
</postal>
<phone></phone>
<email></email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tobias Gondrom" initials="T."
surname="Gondrom">
<organization></organization>
<address>
<postal>
<street>Kruegerstr. 5A</street>
<!-- Reorder these if your country does things differently -->
<city>Unterschleissheim</city>
<region></region>
<code></code>
<country>Germany</country>
</postal>
<phone>+44 7521003005</phone>
<email>tobias.gondrom@gondrom.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="March" year="2011" />
<area>General</area>
<workgroup>WEBSEC</workgroup>
<keyword>frame-options</keyword>
<keyword>HTTP header</keyword>
<keyword>websec</keyword>
<abstract>
<t>To improve the protection of web applications against Cross Site Request Forgery (CSRF)
and Clickjacking this standards defines a http response header that declares a policy
communicated from a host to the client browser whether the transmitted content MUST NOT be displayed in frames of other
pages from different origins or a list of trusted origins which are allowed to frame the content.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In 2009 and 2010 many browser vendors introduced the use of a non-standard http header <xref target="RFC2616">RFC 2616</xref>
"X-Frame-Options" to protect against <xref target="Clickjacking">Clickjacking</xref>
and Cross Site Request Forgery <xref target="CSRF">(CSRF)</xref>. This standard is to replace the non-standard header.</t>
<t>With Clickjacking and CSRF an attacker tricks a user into clicking on a button
or link to another page and by thus executing an unintended command in the
context of a different web application. For example with Clickjacking the attacker
might use transparent or opaque layers to integrate and obscure a button
to another page so that the user may click on it in the expectation of a different action.
So, in this way the attacker is "hijacking" the "Click" on a button meant by the user to be sent to host A,
while clicking the button in effect sends a message to host B.
If the user does for example also have an open session with host B this can lead to a CSRF attack
and executing a command in the session context of the user (using the user's authentication and authorization)
on host B without his intention or knowledge.</t>
<t>The by "Frame-Options" provided defense mechanism against Clickjacking is to allow a secure web page from host B to declare that its content
(for example a button, links, text, etc.) must not be displayed in a frame of another page
(e.g. from host A). In principle this is done by a policy declared in the HTTP header and obeyed
by conform browser implementations.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Frame-Options Header">
<t>The Frame-Options HTTP response header indicates a policy whether a browser MUST
NOT allow to render a page in a<![CDATA[ <frame> or <iframe> ]]>. Hosts can declare this policy in the
header of their HTTP responses to prevent clickjacking attacks, by ensuring that their content
is not embedded into other pages or frames.</t>
<section title="Syntax">
<t>The header field name is:
<vspace /><vspace />
Frame-Options
</t>
<t>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.
<list style="hanging" hangIndent="6">
<t hangText="DENY"><vspace />
A browser receiving content with this header MUST NOT display this content in any frame.</t>
<t hangText="SAMEORIGIN"><vspace />
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.</t>
<t hangText="TRUSTED"> (followed by a list of URIs of trusted origins)<vspace />
A browser receiving content with this header MUST NOT display this content in any frame from a page of different origin than any of the listed origins.
This allows deployment with multi-domain sites, as the webmaster can define a whitelist of origins that are allowed to frame the page.
While this can expose the page to risks by the trusted origins, in some cases it may be necessary to use content from other domains or more than one origin (hostname).</t>
</list>
</t>
</section>
<section title="Backus-Naur Form (BNF)">
<t>The <xref target="RFC0822">RFC 822</xref> EBNF of the Frame-Options header is:<vspace /><vspace />
<figure>
<artwork align="left">
Frame-Options = "Frame-Options" ":" "DENY"/ "SAMEORIGIN" /
("TRUSTED" ":" Origin-List)
Origin-List = 1*URI
</artwork>
</figure>
[TBD] with URI as defined in the websec-origin draft<vspace />
<vspace /> <vspace />
[TBD] Or should we use the ABNF (RFC 2234) alternatively or in addition?<vspace />
<vspace /> <vspace />
</t>
</section>
<section anchor="examples" title="Examples of Frame-Options Headers">
<t></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document was derived from input from specifications published by various browser
vendors like Microsoft (Eric Law, David Ross), Mozilla, Google, Opera and Apple.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo a request to IANA to include the specified HTTP header in registry as outlined in <xref target="RFC3864">Registration Procedures for Message Header Fields</xref></t>
<section anchor="reg-template" title="Registration Template">
<figure align="left" anchor="template">
<preamble></preamble>
<artwork align="left"><![CDATA[
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
Header field name: Frame-Option
Applicable protocol: http [RFC2616]
Status: Standard
Author/Change controller: IETF
Specification document(s): draft-gondrom-frame-options
Related information:
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The introduction of the http header FRAME-OPTIONS does improve the protection against Clickjacking,
however it is not self-sufficient on its own but MUST be used in conjunction with other security measures
like secure coding and Content Security Policy (CSP)
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC822;
&RFC2616;
&RFC3864;
<reference anchor="Clickjacking"
target="http://www.owasp.org/index.php/Clickjacking">
<front>
<title>Clickjacking</title>
<author>
<organization>OWASP (Open Web Application Security Project)</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="CSRF"
target="http://www.owasp.org/index.php/Top_10_2010-A5">
<front>
<title>OWASP Top-10: Cross-Site Request Forgery (CSRF)</title>
<author>
<organization>OWASP (Open Web Application Security Project)</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
<section anchor="app-Clickjacking-description" title="Description of a Clickjacking attack">
<t>More detailed explanation of a Clickjacking attack</t>
</section>
<!-- Change Log
v00 2011-03-06 TG Initial version
v01 2011-03-15 TG Wording and Grammar version
v02 2011-04-05 TG Integrate Discussion of IETF-80 meeting, esp. on parameters
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:35 |