Hacker News Reader

Comment by tptacek | Hacker News Reader

I don't think you read my comment carefully. The difference between XSS "susceptability" between Django and Rails is one setting (safeERB, sanitize, etc). Yes, it's a difference. I don't think it's a particularly meaningful one, because Django autoescape doesn't actually stop XSS attacks, just the stupid ones.

There's a big religious debate inside the Rails community about autoescaping, which ran aground on the point that autoescape doesn't actually stop XSS. I agree with Rails, but concede that reasonable people could think otherwise.

It's hard to see how reasonable, well-informed people could think that mass-assignment was a good default feature.

View on HN

OK, I agree with you that escaping by default only stops some attacks, and if the developer's response is to simply disable the escaping every time they need to display HTML it's not going to be much help.

However, I would argue that nearly every Rails app does have susceptibility to these "trivial" attacks because Rails does not force you to think about when you want to display HTML.

I also agree that people disagree on this. But I still feel the default should always be the secure one.

I don't think that's a crazy point of view. I'm ambivalent. You have easier, better ways to win security arguments about Rails than the lack of one relatively trivial default setting, though.

Can you give an example of an XSS attack that isn't prevented by auto-escaping (other than the UTF-7 one)?

All the attacks that occur in the outputs that you can't auto-escape, because they need to contain HTML by design.

It's not the "escape" that's the problem, it's the "auto".

Gotcha, the HTML sanitization problem. Django doesn't even attempt to solve that, which is probably a bad idea since it inevitably means people will use the various insecure libraries that are out there on the 'net. The trouble is it's /really hard/ to do right - I'd be uncomfortable shipping a sanitizer with Django because I'd worry that some weird undocumented IE parsing error would allow nasty code to slip through and result in a 0-day exploit against the entire framework.

People tend to oversimplify this down to "how to accept HTML in user input", but the problem is more general: lots of applications have two-stage rendering sequences, where data is accepted and stored as HTML, and rendered later.

In the case of web2py there is an object called XML, text passed to the view inside XML is not escaped otherwise it is. You can also do XML(text,sanitize=True) and you can specify which tags and with tag attributes should be allowed. The sanitizer that ships with web2py is the one developed by Josh Goldfoot and posted on activestate, recipe 496942.

Reply on news.ycombinator.com