- From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 02 Aug 2011 21:47:37 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/spec
In directory hutz:/tmp/cvs-serv10427
Modified Files:
Overview.html
Log Message:
Add a section with some authoring advice from a security perspective. This is just a first draft; please feel free to suggest additional material. (whatwg r6346)
Index: Overview.html
===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.5068
retrieving revision 1.5069
diff -u -d -r1.5068 -r1.5069
--- Overview.html 30 Jul 2011 23:45:24 -0000 1.5068
+++ Overview.html 2 Aug 2011 21:47:33 -0000 1.5069
@@ -320,7 +320,7 @@
<h1>HTML5</h1>
<h2 class="no-num no-toc" id="a-vocabulary-and-associated-apis-for-html-and-xhtml">A vocabulary and associated APIs for HTML and XHTML</h2>
- <h2 class="no-num no-toc" id="editor-s-draft-30-july-2011">Editor's Draft 30 July 2011</h2>
+ <h2 class="no-num no-toc" id="editor-s-draft-2-august-2011">Editor's Draft 2 August 2011</h2>
<dl><dt>Latest Published Version:</dt>
<dd><a href="http://www.w3.org/TR/html5/">http://www.w3.org/TR/html5/</a></dd>
<dt>Latest Editor's Draft:</dt>
@@ -466,7 +466,7 @@
Group</a> is the W3C working group responsible for this
specification's progress along the W3C Recommendation
track.
- This specification is the 30 July 2011 Editor's Draft.
+ This specification is the 2 August 2011 Editor's Draft.
</p><!-- UNDER NO CIRCUMSTANCES IS THE PRECEDING PARAGRAPH TO BE REMOVED OR EDITED WITHOUT TALKING TO IAN FIRST --><p>Work on this specification is also done at the <a href="http://www.whatwg.org/">WHATWG</a>. The W3C HTML working group
actively pursues convergence with the WHATWG, as required by the <a href="http://www.w3.org/2007/03/HTML-WG-charter">W3C HTML working
group charter</a>.</p><!-- UNDER NO CIRCUMSTANCES IS THE FOLLOWING PARAGRAPH TO BE REMOVED OR EDITED WITHOUT TALKING TO IAN FIRST --><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
@@ -493,7 +493,9 @@
<ol>
<li><a href="#how-to-read-this-specification"><span class="secno">1.7.1 </span>How to read this specification</a></li>
<li><a href="#typographic-conventions"><span class="secno">1.7.2 </span>Typographic conventions</a></ol></li>
- <li><a href="#a-quick-introduction-to-html"><span class="secno">1.8 </span>A quick introduction to HTML</a></li>
+ <li><a href="#a-quick-introduction-to-html"><span class="secno">1.8 </span>A quick introduction to HTML</a>
+ <ol>
+ <li><a href="#writing-secure-applications-with-html"><span class="secno">1.8.1 </span>Writing secure applications with HTML</a></ol></li>
<li><a href="#conformance-requirements-for-authors"><span class="secno">1.9 </span>Conformance requirements for authors</a>
<ol>
<li><a href="#presentational-markup"><span class="secno">1.9.1 </span>Presentational markup</a></li>
@@ -1689,7 +1691,110 @@
specification might also be of use, but the novice author is
cautioned that this specification, by necessity, defines the
language with a level of detail that might be difficult to
- understand at first.<h3 id="conformance-requirements-for-authors"><span class="secno">1.9 </span>Conformance requirements for authors</h3><p><i>This section is non-normative.</i><p>Unlike previous versions of the HTML specification, this
+ understand at first.<h4 id="writing-secure-applications-with-html"><span class="secno">1.8.1 </span>Writing secure applications with HTML</h4><p><i>This section is non-normative.</i><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>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>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><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.9 </span>Conformance requirements for authors</h3><p><i>This section is non-normative.</i><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><p>However, even though the processing of invalid content is in most
cases well-defined, conformance requirements for documents are still
@@ -72369,6 +72474,7 @@
Philip Jägenstedt,
Philip Taylor,
Philip TAYLOR,
+ Philippe De Ryck,
Prateek Rungta,
Pravir Gupta,
Rachid Finge,
Received on Tuesday, 2 August 2011 21:47:38 UTC