Hacker News new | ask | show | jobs
by eganist 3794 days ago
> [CVE-2015-7578/79] Possible XSS vulnerability in rails-html-sanitizer: You're safe if you use a single page application that properly encode for you. Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good.

So uh, what if your application is taking an input that's then parsed by another application with poor output encoding? Granted, the application that's properly encoding for the correct context is good, but any applications which don't do that but also use that same dataset are screwed because your application didn't perform proper input validation.

Defense in depth strategies exist for a reason. Input validation, output encoding for every single context (this includes using angular properly, for instance), anti-xss headers, CSP, the list goes on. These aren't all prescribed just to protect that one application. They're prescribed so that when applied correctly across all apps, they're all protected from negligence in one app harming the data.

1 comments

Indeed, "any applications which don't do that but also use that same dataset are screwed". You're totally right. I didn't specify whether the encoded string is persisted or not. You considered that it isn't, which leads to the application with poor controls that you mentioned. Nice point. You're also right about defense in depth. I just wanted to highlight when an approach can be dangerous. That's one example, but there are others such as misuse of eval, constantize, etc. If the developer be aware of such risks and implement properly, even some (not all of course) newly disclosed vulnerabilities won't affect the application.
Yup to all others you mentioned. I usually just teach about why trust matters and how to think about it as a developer. Works out well with training the devs at my current workplace. Back to your comments on the CVEs, the reason I replied the way I did was because your comments appeared to come across as being the only necessary mitigations per-se. I know that's not at all how you intended it ("some comments" as opposed to "how to mitigate"), but my first pass over the text made me feel that way about it.

In any case, nice chat. I like productive exchanges.