Skip to content

Instantly share code, notes, and snippets.

What would you like to do?


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.


<div disable-form disable-script disable-link id="user-gen-content">
  <form action="">
  <script src=""></script>
  <link rel="alternate" type="application/atom+xml" href="
{}*{color:red;}//styles/prosilver/theme/feed.php" /> <!-- -->


on event tags

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


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).


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=''><textarea>           ← Injected line
<input type="hidden" name="xsrf_token" value="12345">

##2.3. Rerouting of existing forms

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.