[html5] r6346 - [e] (0) Add a section with some authoring advice from a security perspective. Th [...]
whatwg at whatwg.org
whatwg at whatwg.org
Tue Aug 2 14:47:27 PDT 2011
Author: ianh
Date: 2011-08-02 14:47:26 -0700 (Tue, 02 Aug 2011)
New Revision: 6346
Modified:
complete.html
index
source
Log:
[e] (0) Add a section with some authoring advice from a security perspective. This is just a first draft; please feel free to suggest additional material.
Modified: complete.html
===================================================================
--- complete.html 2011-08-02 19:12:42 UTC (rev 6345)
+++ complete.html 2011-08-02 21:47:26 UTC (rev 6346)
@@ -296,7 +296,9 @@
<ol>
<li><a href=#how-to-read-this-specification><span class=secno>1.8.1 </span>How to read this specification</a></li>
<li><a href=#typographic-conventions><span class=secno>1.8.2 </span>Typographic conventions</a></ol></li>
- <li><a href=#a-quick-introduction-to-html><span class=secno>1.9 </span>A quick introduction to HTML</a></li>
+ <li><a href=#a-quick-introduction-to-html><span class=secno>1.9 </span>A quick introduction to HTML</a>
+ <ol>
+ <li><a href=#writing-secure-applications-with-html><span class=secno>1.9.1 </span>Writing secure applications with HTML</a></ol></li>
<li><a href=#conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</a>
<ol>
<li><a href=#presentational-markup><span class=secno>1.10.1 </span>Presentational markup</a></li>
@@ -2135,10 +2137,123 @@
understand at first.</p>
- <h3 id=conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</h3>
+ <h4 id=writing-secure-applications-with-html><span class=secno>1.9.1 </span>Writing secure applications with HTML</h4>
<p><i>This section is non-normative.</i></p>
+ <p>When HTML is used to create interactive sites, care needs to be
+ taken to avoid introducing vulnerabilities through which attackers
+ can compromise the integrity of the site itself or of the site's
+ users.</p>
+
+ <p>A comprehensive study of this matter is beyond the scope of this
+ document, and authors are strongly encouraged to study the matter in
+ more detail. However, this section attempts to provide a quick
+ introduction to some common pitfalls in HTML application
+ development.</p>
+
+ <p>The security model of the Web is based on the concept of
+ "origins", and correspondingly many of the potential attacks on the
+ Web involve cross-origin actions. <a href=#refsORIGIN>[ORIGIN]</a></p>
+
+ <dl><dt>Not validating user input</dt>
+ <dt>Cross-site scripting (XSS)</dt>
+ <dt>SQL injection</dt>
+
+ <dd>
+
+ <p>When accepting untrusted input, e.g. user-generated content
+ such as text comments, values in URL parameters, messages from
+ third-party sites, etc, it is imperative that the data be
+ validated before use, and properly escaped when displayed. Failing
+ to do this can allow an hostile user to perform a variety of
+ attacks, ranging from the potentially benign, such as providing
+ bogus user information like a negative age, to the serious, such
+ as running scripts every time a user looks at a page that includes
+ the information, potentially propagating the attack in the
+ process, to the catastrophic, such as deleting all data in the
+ server.</p>
+
+ <div class=example>
+
+ <p>For example, suppose a page looked at its URL's query string
+ to determine what to display, and the site then redirected the
+ user to that page to display a message, as in:</p>
+
+ <pre><ul>
+ <li><a href="message.cgi?say=Hello">Say Hello</a>
+ <li><a href="message.cgi?say=Welcome">Say Welcome</a>
+ <li><a href="message.cgi?say=Kittens">Say Kittens</a>
+</ul></pre>
+
+ <p>If the message was just displayed to the user without
+ escaping, a hostile attacker could then craft a URL that
+ contained a script element:</p>
+
+ <pre>http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E</pre>
+
+ <p>If the attacker then convinced a victim user to visit this
+ page, a script of the attacker's choosing would run on the page.
+ Such a script could do any number of hostile actions, limited
+ only by what the site offers: if the site is an e-commerce shop,
+ for instance, such a script could cause the user to unknowingly
+ make arbitrarily many unwanted purchases.</p>
+
+ <p>This is called a cross-site scripting attack.</p>
+
+ </pre></div>
+
+ </dd>
+
+
+ <dt>Cross-site request forgery (CSRF)</dt>
+
+ <dd>
+
+ <p>If a site allows a user to make form submissions with
+ user-specific side-effects, for example posting messages on a
+ forum under the user's name, making purchases, or applying for a
+ passport, it is important to verify that the request was made by
+ the user intentionally, rather than by another site tricking the
+ user into making the request unknowingly.</p>
+
+ <p>This problem exists because HTML forms can be submitted to
+ other origins.</p>
+
+ <p>Sites can prevent such attacks by populating forms with
+ user-specific hidden tokens, or by checking <code title=http-origin>Origin</code> headers on all requests.</p>
+
+ </dd>
+
+
+
+ <dt>Clickjacking</dt>
+
+ <dd>
+
+ <p>A page that provides users with an interface to perform actions
+ that the user might not wish to perform needs to be designed so as
+ to avoid the possibility that users can be tricked into activating
+ the interface.</p>
+
+ <p>One way that a user could be so tricked is if a hostile site
+ places the victim site in a small <code><a href=#the-iframe-element>iframe</a></code> and then
+ convinces the user to click, for instance by having the user play
+ a reaction game. Once the user is playing the game, the hostile
+ site can quickly position the iframe under the mouse cursor just
+ as the user is about to click, thus tricking the user into
+ clicking the victim site's interface.</p>
+
+ <p>To avoid this, sites that do not expect to be used in frames
+ are encouraged to only enable their interface if they detect that
+ they are not in a frame (e.g. by comparing the <code title=dom-window><a href=#dom-window>window</a></code> object to the value of the <code title=dom-top><a href=#dom-top>top</a></code> attribute).</p>
+
+ </dd>
+
+ </dl><h3 id=conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</h3>
+
+ <p><i>This section is non-normative.</i></p>
+
<p>Unlike previous versions of the HTML specification, this
specification defines in some detail the required processing for
invalid documents as well as valid documents.</p> <!-- This has led
@@ -101265,6 +101380,7 @@
Philip Jägenstedt,
Philip Taylor,
Philip TAYLOR<!-- a different one -->,
+ Philippe De Ryck,
Prateek Rungta,
Pravir Gupta,
Rachid Finge,
Modified: index
===================================================================
--- index 2011-08-02 19:12:42 UTC (rev 6345)
+++ index 2011-08-02 21:47:26 UTC (rev 6346)
@@ -296,7 +296,9 @@
<ol>
<li><a href=#how-to-read-this-specification><span class=secno>1.8.1 </span>How to read this specification</a></li>
<li><a href=#typographic-conventions><span class=secno>1.8.2 </span>Typographic conventions</a></ol></li>
- <li><a href=#a-quick-introduction-to-html><span class=secno>1.9 </span>A quick introduction to HTML</a></li>
+ <li><a href=#a-quick-introduction-to-html><span class=secno>1.9 </span>A quick introduction to HTML</a>
+ <ol>
+ <li><a href=#writing-secure-applications-with-html><span class=secno>1.9.1 </span>Writing secure applications with HTML</a></ol></li>
<li><a href=#conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</a>
<ol>
<li><a href=#presentational-markup><span class=secno>1.10.1 </span>Presentational markup</a></li>
@@ -2037,10 +2039,123 @@
understand at first.</p>
- <h3 id=conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</h3>
+ <h4 id=writing-secure-applications-with-html><span class=secno>1.9.1 </span>Writing secure applications with HTML</h4>
<p><i>This section is non-normative.</i></p>
+ <p>When HTML is used to create interactive sites, care needs to be
+ taken to avoid introducing vulnerabilities through which attackers
+ can compromise the integrity of the site itself or of the site's
+ users.</p>
+
+ <p>A comprehensive study of this matter is beyond the scope of this
+ document, and authors are strongly encouraged to study the matter in
+ more detail. However, this section attempts to provide a quick
+ introduction to some common pitfalls in HTML application
+ development.</p>
+
+ <p>The security model of the Web is based on the concept of
+ "origins", and correspondingly many of the potential attacks on the
+ Web involve cross-origin actions. <a href=#refsORIGIN>[ORIGIN]</a></p>
+
+ <dl><dt>Not validating user input</dt>
+ <dt>Cross-site scripting (XSS)</dt>
+ <dt>SQL injection</dt>
+
+ <dd>
+
+ <p>When accepting untrusted input, e.g. user-generated content
+ such as text comments, values in URL parameters, messages from
+ third-party sites, etc, it is imperative that the data be
+ validated before use, and properly escaped when displayed. Failing
+ to do this can allow an hostile user to perform a variety of
+ attacks, ranging from the potentially benign, such as providing
+ bogus user information like a negative age, to the serious, such
+ as running scripts every time a user looks at a page that includes
+ the information, potentially propagating the attack in the
+ process, to the catastrophic, such as deleting all data in the
+ server.</p>
+
+ <div class=example>
+
+ <p>For example, suppose a page looked at its URL's query string
+ to determine what to display, and the site then redirected the
+ user to that page to display a message, as in:</p>
+
+ <pre><ul>
+ <li><a href="message.cgi?say=Hello">Say Hello</a>
+ <li><a href="message.cgi?say=Welcome">Say Welcome</a>
+ <li><a href="message.cgi?say=Kittens">Say Kittens</a>
+</ul></pre>
+
+ <p>If the message was just displayed to the user without
+ escaping, a hostile attacker could then craft a URL that
+ contained a script element:</p>
+
+ <pre>http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E</pre>
+
+ <p>If the attacker then convinced a victim user to visit this
+ page, a script of the attacker's choosing would run on the page.
+ Such a script could do any number of hostile actions, limited
+ only by what the site offers: if the site is an e-commerce shop,
+ for instance, such a script could cause the user to unknowingly
+ make arbitrarily many unwanted purchases.</p>
+
+ <p>This is called a cross-site scripting attack.</p>
+
+ </pre></div>
+
+ </dd>
+
+
+ <dt>Cross-site request forgery (CSRF)</dt>
+
+ <dd>
+
+ <p>If a site allows a user to make form submissions with
+ user-specific side-effects, for example posting messages on a
+ forum under the user's name, making purchases, or applying for a
+ passport, it is important to verify that the request was made by
+ the user intentionally, rather than by another site tricking the
+ user into making the request unknowingly.</p>
+
+ <p>This problem exists because HTML forms can be submitted to
+ other origins.</p>
+
+ <p>Sites can prevent such attacks by populating forms with
+ user-specific hidden tokens, or by checking <code title=http-origin>Origin</code> headers on all requests.</p>
+
+ </dd>
+
+
+
+ <dt>Clickjacking</dt>
+
+ <dd>
+
+ <p>A page that provides users with an interface to perform actions
+ that the user might not wish to perform needs to be designed so as
+ to avoid the possibility that users can be tricked into activating
+ the interface.</p>
+
+ <p>One way that a user could be so tricked is if a hostile site
+ places the victim site in a small <code><a href=#the-iframe-element>iframe</a></code> and then
+ convinces the user to click, for instance by having the user play
+ a reaction game. Once the user is playing the game, the hostile
+ site can quickly position the iframe under the mouse cursor just
+ as the user is about to click, thus tricking the user into
+ clicking the victim site's interface.</p>
+
+ <p>To avoid this, sites that do not expect to be used in frames
+ are encouraged to only enable their interface if they detect that
+ they are not in a frame (e.g. by comparing the <code title=dom-window><a href=#dom-window>window</a></code> object to the value of the <code title=dom-top><a href=#dom-top>top</a></code> attribute).</p>
+
+ </dd>
+
+ </dl><h3 id=conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</h3>
+
+ <p><i>This section is non-normative.</i></p>
+
<p>Unlike previous versions of the HTML specification, this
specification defines in some detail the required processing for
invalid documents as well as valid documents.</p> <!-- This has led
@@ -96995,6 +97110,7 @@
Philip Jägenstedt,
Philip Taylor,
Philip TAYLOR<!-- a different one -->,
+ Philippe De Ryck,
Prateek Rungta,
Pravir Gupta,
Rachid Finge,
Modified: source
===================================================================
--- source 2011-08-02 19:12:42 UTC (rev 6345)
+++ source 2011-08-02 21:47:26 UTC (rev 6346)
@@ -929,6 +929,128 @@
understand at first.</p>
+ <h4>Writing secure applications with HTML</h4>
+
+ <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
+
+ <p>When HTML is used to create interactive sites, care needs to be
+ taken to avoid introducing vulnerabilities through which attackers
+ can compromise the integrity of the site itself or of the site's
+ users.</p>
+
+ <p>A comprehensive study of this matter is beyond the scope of this
+ document, and authors are strongly encouraged to study the matter in
+ more detail. However, this section attempts to provide a quick
+ introduction to some common pitfalls in HTML application
+ development.</p>
+
+ <p>The security model of the Web is based on the concept of
+ "origins", and correspondingly many of the potential attacks on the
+ Web involve cross-origin actions. <a
+ href="#refsORIGIN">[ORIGIN]</a></p>
+
+ <dl>
+
+ <dt>Not validating user input</dt>
+ <dt>Cross-site scripting (XSS)</dt>
+ <dt>SQL injection</dt>
+
+ <dd>
+
+ <p>When accepting untrusted input, e.g. user-generated content
+ such as text comments, values in URL parameters, messages from
+ third-party sites, etc, it is imperative that the data be
+ validated before use, and properly escaped when displayed. Failing
+ to do this can allow an hostile user to perform a variety of
+ attacks, ranging from the potentially benign, such as providing
+ bogus user information like a negative age, to the serious, such
+ as running scripts every time a user looks at a page that includes
+ the information, potentially propagating the attack in the
+ process, to the catastrophic, such as deleting all data in the
+ server.</p>
+
+ <div class="example">
+
+ <p>For example, suppose a page looked at its URL's query string
+ to determine what to display, and the site then redirected the
+ user to that page to display a message, as in:</p>
+
+ <pre><ul>
+ <li><a href="message.cgi?say=Hello">Say Hello</a>
+ <li><a href="message.cgi?say=Welcome">Say Welcome</a>
+ <li><a href="message.cgi?say=Kittens">Say Kittens</a>
+</ul></pre>
+
+ <p>If the message was just displayed to the user without
+ escaping, a hostile attacker could then craft a URL that
+ contained a script element:</p>
+
+ <pre>http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E</pre>
+
+ <p>If the attacker then convinced a victim user to visit this
+ page, a script of the attacker's choosing would run on the page.
+ Such a script could do any number of hostile actions, limited
+ only by what the site offers: if the site is an e-commerce shop,
+ for instance, such a script could cause the user to unknowingly
+ make arbitrarily many unwanted purchases.</p>
+
+ <p>This is called a cross-site scripting attack.</p>
+
+ </div>
+
+ </dd>
+
+
+ <dt>Cross-site request forgery (CSRF)</dt>
+
+ <dd>
+
+ <p>If a site allows a user to make form submissions with
+ user-specific side-effects, for example posting messages on a
+ forum under the user's name, making purchases, or applying for a
+ passport, it is important to verify that the request was made by
+ the user intentionally, rather than by another site tricking the
+ user into making the request unknowingly.</p>
+
+ <p>This problem exists because HTML forms can be submitted to
+ other origins.</p>
+
+ <p>Sites can prevent such attacks by populating forms with
+ user-specific hidden tokens, or by checking <code
+ title="http-origin">Origin</code> headers on all requests.</p>
+
+ </dd>
+
+
+
+ <dt>Clickjacking</dt>
+
+ <dd>
+
+ <p>A page that provides users with an interface to perform actions
+ that the user might not wish to perform needs to be designed so as
+ to avoid the possibility that users can be tricked into activating
+ the interface.</p>
+
+ <p>One way that a user could be so tricked is if a hostile site
+ places the victim site in a small <code>iframe</code> and then
+ convinces the user to click, for instance by having the user play
+ a reaction game. Once the user is playing the game, the hostile
+ site can quickly position the iframe under the mouse cursor just
+ as the user is about to click, thus tricking the user into
+ clicking the victim site's interface.</p>
+
+ <p>To avoid this, sites that do not expect to be used in frames
+ are encouraged to only enable their interface if they detect that
+ they are not in a frame (e.g. by comparing the <code
+ title="dom-window">window</code> object to the value of the <code
+ title="dom-top">top</code> attribute).</p>
+
+ </dd>
+
+ </dl>
+
+
<h3>Conformance requirements for authors</h3>
<!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
@@ -115442,6 +115564,7 @@
Philip Jägenstedt,
Philip Taylor,
Philip TAYLOR<!-- a different one -->,
+ Philippe De Ryck,
Prateek Rungta,
Pravir Gupta,
Rachid Finge,
More information about the Commit-Watchers
mailing list