HTML5 Security Cheatsheet: What your browser does when you look away...
html5sec.org
html5sec.org
Letting your users write HTML/CSS (or not escaping input) is a bad idea to begin with.
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.
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.
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.
I have exploited the embedding of Flash to do XSS before. It's funny that while the site I was on heavily filtered any JS input in its rich text editor, you could easily upload a Flash file (served from the SAME domain!), and XSS it.
Although this sounds quite clever, I don't see the value in this. If your HTML whitelist contains "on..." attributes such as "onscroll", you have deeper issues than this clever trick. Almost certainly you are vulnerable to stuff like "onclick", too.
Except if you use blacklists where you added "onclick" and forgot to add "onscroll". But in that case, if you are using blacklists instead of whitelists, you are almost certainly doomed anyway. (see https://news.ycombinator.com/item?id=4794745)
If it's about things that can happen if you embed user (read: attacker) provided content in your page then you have already lost. There's never a time that you can safely embed content from an untrusted source in your page - no blacklist or whitelist based approach to content is going to be safe. The correct approach to user provided content is to parse the content, drop anything you don't understand or recognize exactly. Then escape all of the left over content, and reconstruct at the end.
You could use markdown to do this for you, or you could do it manually if you want you own rules (and/or <>-like syntax).
Filtering content is just not sound and every time I see something that seems to imply that it is, it makes me cry.
(A example of this taken to its extreme is WebGL shader parsing. A correct + "safe" implementation of WebGL must at the very least: 1. parse the shader itself, dropping all comments, etc 2. perform strict semantic analysis on the result of <1> (especially as many GL drivers don't) 3. take the result of <2> and turn that back into text 4. throw the result of <3> at the gl engine
This is necessary to ensure that not only is the shader correct (in the terms of webgl), but also to ensure that no parsing oddities can get through (e.g. something seen as a comment terminator in the driver but not the validator - bugs like this have happened with multiple validators in multiple contexts over the last few decades)