4 ms·

I don't get it. This page basically shows all available event handlers and other attributes for HTML elements and says "you can put JavaScript here". Well, than

I don't get it. This page basically shows all available event handlers and other attributes for HTML elements and says "you can put JavaScript here". Well, thanks. Letting your users write HTML/CSS (or not escaping input) is a bad idea to begin with.

benmanns 14y ago
Sometimes you have to allow some user input, like , , or tags in those WYSIWYG editors. This is a reference for what you should remove from your whitelist or add to your blacklist.
- Adirael 14y ago
 Still, OP's right. If you need to let them use plain HTML (it's better to use markdown or something similar) just parse it and remove any attributes and tags not on your whitelist.
 - TeMPOraL 14y ago
 Or make them use Markdown, org-mode syntax, BBCode or s-expressions ({b text in bold {i and italics}}). User formatting should never go directly to the browser, without being reinterpreted by the website.
- vog 14y ago
 I can't believe anyone has attributes like "onfocus" on their whitelist. Although I respect the site's aim for completeness, the whole site could be shortened to one example of each issue. One example of "on..." attributes, one example of "javascript:" URLs, and so on. I don't see the value of the second, third, yet-another "on..." example. This is just hiding the deeper issues in a mess of seemingly clever examples. Regarding the blacklist proposal, I really hope that nobody is seriously using those for HTML! One typo, one forgotten entry, or one new browser feature, and the blacklist's security drops to zero.
- tptacek 14y ago
 The right way to handle this problem is to scrape the content out of the incoming HTML, do a best-effort pass at remembering the formatting rules expressed in it, entity-encode everything, and regenerate the HTML markup from scratch. It is never a good idea to accept HTML from a client, attempt to clean it up, and then pass it directly into the DOM of a server-generated page.
laumars 14y ago
Yeah I thought this, however there are some useful gems in there, the Javascript embedded in SVG images being one example. It's just a pity the good content is so watered down with dozens of obvious "you should sanitised user input" examples and variations of the same attacks.
VMG 14y ago
I have the suspicion this might not be a guide for people who want to prevent attacks, but a guide for people who want to attack poorly secured sites.

benmanns 14y ago

Sometimes you have to allow some user input, like , , or tags in those WYSIWYG editors. This is a reference for what you should remove from your whitelist or add to your blacklist.

Adirael 14y ago
Still, OP's right. If you need to let them use plain HTML (it's better to use markdown or something similar) just parse it and remove any attributes and tags not on your whitelist.
- TeMPOraL 14y ago
  Or make them use Markdown, org-mode syntax, BBCode or s-expressions ({b text in bold {i and italics}}). User formatting should never go directly to the browser, without being reinterpreted by the website.
vog 14y ago
I can't believe anyone has attributes like "onfocus" on their whitelist. Although I respect the site's aim for completeness, the whole site could be shortened to one example of each issue. One example of "on..." attributes, one example of "javascript:" URLs, and so on. I don't see the value of the second, third, yet-another "on..." example. This is just hiding the deeper issues in a mess of seemingly clever examples. Regarding the blacklist proposal, I really hope that nobody is seriously using those for HTML! One typo, one forgotten entry, or one new browser feature, and the blacklist's security drops to zero.
tptacek 14y ago
The right way to handle this problem is to scrape the content out of the incoming HTML, do a best-effort pass at remembering the formatting rules expressed in it, entity-encode everything, and regenerate the HTML markup from scratch. It is never a good idea to accept HTML from a client, attempt to clean it up, and then pass it directly into the DOM of a server-generated page.

laumars 14y ago

Yeah I thought this, however there are some useful gems in there, the Javascript embedded in SVG images being one example. It's just a pity the good content is so watered down with dozens of obvious "you should sanitised user input" examples and variations of the same attacks.

VMG 14y ago

I have the suspicion this might not be a guide for people who want to prevent attacks, but a guide for people who want to attack poorly secured sites.