Comment by chime | Hacker News Reader

Comment by chime | Hacker News Reader

Parent Full thread

> It's not rocket science

I know. But it isn't cakewalk either when you take Unicode/UTF etc. into consideration. Myspace, Twitter, Facebook, and now YouTube have been bitten by it, some multiple times. My point is, with so much social content being user-generated, there is absolutely no way to wall-off the user-content easily. You have to manually make sure every piece of user data is parsed and filtered, and most developers do that but it's not easy.

Show me the code that allows users to enter basic HTML (<a>, <b>, <p>, <u>) while preventing the bad stuff (<script>, <body>). Now make this code allow <a> to have attributes like href, title but not onclick, onmouseout. Allow <p> to have style attributes for font-family but not width:expression(400 + "px") style because that's another way to run JS in IE. You'll quickly see how it gets difficult really quick.

The solution for most sites (including reddit/HN) is to use Markdown. It's not a perfect solution but it works for sites where data entry is restricted to a few fields. YouTube is so large and has so many places where users can enter arbitrary data that it is not simple to ensure there are no bugs anywhere.

Again, I don't understand how my solution (a) fails in preventing all XSS hacks that we've seen so far. Each hack worked because users could insert JS code into a form that was not properly filtered. What is harder? Making sure every single web form on the Internet has 0 sanitization bugs or adding a single meta-tag to top browsers that says "Hey, don't run any inline JS."

I may be naive, but how about this?

a) Escape everything 100%.

b) Look for <a> tags, grab their href attribute, escape it, and insert them as <a href='$1'>$2</a>.

c) Do the same for <b>, <p>, etc.

How would that be vulnerable to XSS? A small whitelist of HTML would be replaced safely, and any script tags and so on would be escaped and displayed as is.

In your example above, $1 may contain javascript. The easy way is href="data:text/javascript", or even href="javascript:alert('foo')"", but there are probably a dozen other ways, including data:image/svg.

There's no real way to "escape" url attributes (some browsers are known to run 'any: ex' as javascript); parsing the url seems to be the only approach that works.

So only allow http:// and https:// in URLs?

>> "show me the code that allows users to enter basic HTML (<a>, <b>, <p>, <u>) while preventing the bad stuff (<script>, <body>)."

1. Disallow everything. Escape everything 100%. 2. Now selectively parse out the original and recreate what is explicitly allowed. Do not include anything from the input in the code portions of the output that hasn't been completely sanitized.

This isn't a hard problem. It's like asking "Make a firewall that allows mysql through and ssh, but nothing else". The thing is, people make mistakes, and developers are often lazy.

>> "Making sure every single web form on the Internet has 0 sanitization bugs or adding a single meta-tag to top browsers that says "Hey, don't run any inline JS."

Asking the browser to do your security for you seems pretty lazy. If you can't manage to escape HTML properly, what other security issues are there likely to be that the browser can't help with? SQL injections?

> selectively parse out the original and recreate what is explicitly allowed.

This is the ONLY solution. trying to blacklist and escape characters is ultimately trying to push your parsing problem down to the browser, and what will you do when the browser contains a bug that someone can exploit to steal your own credentials on the web app?

I'm a strong believer in using JS to inject unsafe text directly into the DOM. If you want people to mark stuff up, give them a markup language that you parse. Note that Markdown has its issues: If you use a library to parse it, be aware that html is valid markdown, so you're just moving the HTML escape problem around.

Reply on news.ycombinator.com