Hacker News Reader

Comment by johns | Hacker News Reader

I think it's an overly complicated solution for the stated problem. He shows insecure code that no one should use (unvalidated input through Request[]) and then solves it with an extremely kludgey solution. Same with the redirect problem he states. If you validate that the redirect is valid before making it, that problem is solved. The point being, as always, validate all input. Adding layers of complexity as a security "solution" compared to simple validation is a pretty crazy idea and a lot of unneeded complexity.

View on HN

??? Doesn't every secure programming book start out with insecure code and then demonstrate how to properly fix it?

I have no problem with the stated problem. I have an issue with taking that problem, dismissing the common solution (input validation) and then presenting an overly-complex "solution."

Is this overly-complex? Yes.

Are there things any ASP.NET app should be doing before using evasion techniques to avoid XSS? Sure. For what it's worth, the best practice is output filtering, not simple input validation.

Does this make the MSDN article "crazy"? Of course not. This is another layer of defense, and it's not a totally inappropriate one for an internal app, even if I'd never recommend it to a client.

Stop picking on the VB.NET developers. They have different problems than you do.

This is a "crazy" article, even more so if the audience is for VB developers. Using the assumption that VB developers are "business" programmers, the solution presented in the article adds more code than necessary, and the more code, the more room for error. If this code were to propagate into the world, at some point, when a user requests to be able to bookmark a page, the whole thing would need to be ripped out and the person who believes in this solution would try to re-engineer this solution to try to play well with bookmarks.

The simple solution of validating input and generating the right output, like parameter binding instead of string concatenation to prevent sql injection attacks, should be sufficient, and compliant to other www features. The article basically could've been a page shorter.

MSDN already has dozens of articles on input filtering, output filtering, and safe SQL usage (note that this article isn't even intended to address SQL). But you're not commenting on those, because you don't read MSDN; you're just jumping on this one article out of context.

It seems like you're defending this article on the sole basis that it exists and may be helpful to a set of programmers that find this helpful, but shouldn't. Personally, I read plenty of stuff on MSDN (I'm a .NET dev for work and for fun) so I'm familiar with the territory. If there are already enough articles on it, why write another one that's not particularly useful and can lead devs down rabbit holes they don't want to be in?

Reply on news.ycombinator.com