[html5] r6875 - [e] (0) Mention some XSS risks explicitly. Affected topics: HTML, Security

whatwg at whatwg.org whatwg at whatwg.org
Thu Dec 15 16:32:37 PST 2011


Author: ianh
Date: 2011-12-15 16:32:35 -0800 (Thu, 15 Dec 2011)
New Revision: 6875

Modified:
   complete.html
   index
   source
Log:
[e] (0) Mention some XSS risks explicitly.
Affected topics: HTML, Security

Modified: complete.html
===================================================================
--- complete.html	2011-12-15 00:44:21 UTC (rev 6874)
+++ complete.html	2011-12-16 00:32:35 UTC (rev 6875)
@@ -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 — Last Updated 15 December 2011</h2>
+    <h2 class="no-num no-toc">Living Standard — 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,9 +2222,30 @@
 
     </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>
 
    <dd>

Modified: index
===================================================================
--- index	2011-12-15 00:44:21 UTC (rev 6874)
+++ index	2011-12-16 00:32:35 UTC (rev 6875)
@@ -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 — Last Updated 15 December 2011</h2>
+    <h2 class="no-num no-toc">Living Standard — 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,9 +2222,30 @@
 
     </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>
 
    <dd>

Modified: source
===================================================================
--- source	2011-12-15 00:44:21 UTC (rev 6874)
+++ source	2011-12-16 00:32:35 UTC (rev 6875)
@@ -1048,6 +1048,34 @@
 
     </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>
 
 




More information about the Commit-Watchers mailing list