Examine possible other vulnerabilities that may make sense to support

[LukeWood]

Hey @mozfreddyb,

Now that Typescript support is wrapping up I'd like to run something by you!

I've been working on a suite of rules to run over various frontends to scan for xss vulnerabilities. The list of xss sinks I'd like the suite to handle are:

• innerHTML, insertAdjacentHTML document.write (done by your plugin)
• dangerouslySetInnerHTML (react)
• eval
• setTimeout (passing user defined strings here)
• setInterval (passing user defined strings here)
• sets to window.location
• script.src writes
• a.href
• base64
• controlled react props (not sure if this is feasible to scan for via a linter)

Do any of these seem like good fits to add to eslint-plugin-no-unsanitized? If so I'd like to offer my help in the development process.

[mozfreddyb]

I want to prevent this eslint plugin from being a one-stop-shop for all things dangerous JavaScript. It wouldn't be super immediately useful for the ways we are using the plugin at Mozilla.

The issues with assignments to script.src, a.href, window.location, and react props are really only possible with type annotations, which makes it tricky to support fully. There are also lots of rules out there that do the things you're listing above, e.g.

• dangerouslySetInnerHTML: eslint-plugin-react/no-danger
• eval: eslint/no-eval
• setTimeout, setInterval: eslint/no-implied-eval
• base64: Makes no sense to disallow imho. Now you're suddenly looking at sources of bad data (which could be anywhere, including location.search, location.hash and what not). I think we're safe if we focus on the sinks instead (innerHTML, document.write etc.)

[LukeWood]

sounds good & totally understand.

Thanks Frederik!