Live data from Hacker News

HTML5 Security Cheatsheet: What your browser does when you look away...

html5sec.org

11–15 of 15 posts

Re: HTML5 Security Cheatsheet: What your browser does when you look away...

#11

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.

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.

Re: HTML5 Security Cheatsheet: What your browser does when you look away...

#12
post #4

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.

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.

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.

Re: HTML5 Security Cheatsheet: What your browser does when you look away...

#13

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.

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.

Re: HTML5 Security Cheatsheet: What your browser does when you look away...

#14
post #10

Quite a list. Kinda makes me feel bad for all the people writing HTML sanitizers :(

It's really not that difficult if you use a parser + whitelist. You don't have to care about this sort of thing if you limit people to using certain tags/attributes in WYSIWYG editors and other inputs.

Re: HTML5 Security Cheatsheet: What your browser does when you look away...

#15
I'm not sure what this is saying. If it's talking about things the browser can be made to do my response is "so? that's intentional".

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 (especially as many GL drivers don't) 3. take the result of and turn that back into text 4. throw the result of 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)

Post reply on HN