[e] (0) Mention some XSS risks explicitly.

Affected topics: HTML, Security git-svn-id: http://svn.whatwg.org/webapps@6875 340c8d12-0b0e-0410-8428-c7bf67bfef74
whatwg · Dec 16, 2011 · 94ea55a · 94ea55a
1 parent 3e7af92
commit 94ea55a
Show file tree

Hide file tree

Showing 3 changed files with 74 additions and 4 deletions.
diff --git a/complete.html b/complete.html
@@ -240,7 +240,7 @@
 
   <header class=head id=head><p><a class=logo href=http://www.whatwg.org/><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
    <hgroup><h1 class=allcaps>HTML</h1>
-    <h2 class="no-num no-toc">Living Standard &mdash; Last Updated 15 December 2011</h2>
+    <h2 class="no-num no-toc">Living Standard &mdash; Last Updated 16 December 2011</h2>
    </hgroup><dl><dt><strong>Web developer edition:</strong></dt>
     <dd><strong><a href=http://developers.whatwg.org/>http://developers.whatwg.org/</a></strong></dd>
     <dt>Multiple-page version:</dt>
@@ -2222,7 +2222,28 @@ <h4 id=writing-secure-applications-with-html><span class=secno>1.10.1 </span>Wri
 
     </div>
 
-   </dd>
+    <p>There are many constructs that can be used to try to trick a
+    site into executing code. Here are some that authors are
+    encouraged to consider when writing whitelist filters:</p>
+
+    <ul><li>When allowing harmless-seeming elements like
+     <code><a href=#the-img-element>img</a></code>, it is important to whitelist any provided
+     attributes as well. If one allowed all attributes then an
+     attacker could, for instance, use the <code title=handler-onload><a href=#handler-onload>onload</a></code> attribute to run arbitrary
+     script.</li>
+
+     <li>When allowing URLs to be provided (e.g. for links), the
+     scheme of each URL also needs to be explicitly whitelisted, as
+     there are many schemes that can be abused. The most prominent
+     example is "<code agents="" but="" can="" have="" historically="" implement="" implemented="" indeed="" others="" title="javascript:</code>" user=""> <!-- IE had vbscript:, Netscape had livescript:,
+     etc. -->
+
+     <li>Allowing a <code><a href=#the-base-element>base</a></code> element to be inserted means any
+     <code><a href=#the-script-element>script</a></code> elements in the page with relative links can
+     be hijacked, and similarly that any form submissions can get
+     redirected to a hostile site.</li>
+
+    </code></ul></dd>
 
 
    <dt>Cross-site request forgery (CSRF)</dt>

diff --git a/index b/index
@@ -240,7 +240,7 @@
 
   <header class=head id=head><p><a class=logo href=http://www.whatwg.org/><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
    <hgroup><h1 class=allcaps>HTML</h1>
-    <h2 class="no-num no-toc">Living Standard &mdash; Last Updated 15 December 2011</h2>
+    <h2 class="no-num no-toc">Living Standard &mdash; Last Updated 16 December 2011</h2>
    </hgroup><dl><dt><strong>Web developer edition:</strong></dt>
     <dd><strong><a href=http://developers.whatwg.org/>http://developers.whatwg.org/</a></strong></dd>
     <dt>Multiple-page version:</dt>
@@ -2222,7 +2222,28 @@ a.setAttribute('href', 'http://example.com/'); // change the content attribute d
 
     </div>
 
-   </dd>
+    <p>There are many constructs that can be used to try to trick a
+    site into executing code. Here are some that authors are
+    encouraged to consider when writing whitelist filters:</p>
+
+    <ul><li>When allowing harmless-seeming elements like
+     <code><a href=#the-img-element>img</a></code>, it is important to whitelist any provided
+     attributes as well. If one allowed all attributes then an
+     attacker could, for instance, use the <code title=handler-onload><a href=#handler-onload>onload</a></code> attribute to run arbitrary
+     script.</li>
+
+     <li>When allowing URLs to be provided (e.g. for links), the
+     scheme of each URL also needs to be explicitly whitelisted, as
+     there are many schemes that can be abused. The most prominent
+     example is "<code agents="" but="" can="" have="" historically="" implement="" implemented="" indeed="" others="" title="javascript:</code>" user=""> <!-- IE had vbscript:, Netscape had livescript:,
+     etc. -->
+
+     <li>Allowing a <code><a href=#the-base-element>base</a></code> element to be inserted means any
+     <code><a href=#the-script-element>script</a></code> elements in the page with relative links can
+     be hijacked, and similarly that any form submissions can get
+     redirected to a hostile site.</li>
+
+    </code></ul></dd>
 
 
    <dt>Cross-site request forgery (CSRF)</dt>

diff --git a/source b/source
@@ -1048,6 +1048,34 @@ a.setAttribute('href', 'http://example.com/'); // change the content attribute d
 
     </div>
 
+    <p>There are many constructs that can be used to try to trick a
+    site into executing code. Here are some that authors are
+    encouraged to consider when writing whitelist filters:</p>
+
+    <ul>
+
+     <li>When allowing harmless-seeming elements like
+     <code>img</code>, it is important to whitelist any provided
+     attributes as well. If one allowed all attributes then an
+     attacker could, for instance, use the <code
+     title="handler-onload">onload</code> attribute to run arbitrary
+     script.</li>
+
+     <li>When allowing URLs to be provided (e.g. for links), the
+     scheme of each URL also needs to be explicitly whitelisted, as
+     there are many schemes that can be abused. The most prominent
+     example is "<code title="javascript:</code>", but user agents can
+     implement (and indeed, have historically implemented)
+     others.</li> <!-- IE had vbscript:, Netscape had livescript:,
+     etc. -->
+
+     <li>Allowing a <code>base</code> element to be inserted means any
+     <code>script</code> elements in the page with relative links can
+     be hijacked, and similarly that any form submissions can get
+     redirected to a hostile site.</li>
+
+    </ul>
+
    </dd>