[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