3 ms·

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

johns 17y ago
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."
- tptacek 17y ago
  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.
  - bfung 17y ago
    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.
    - tptacek 17y ago
      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.
      - johns 17y ago
        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?

johns 17y ago

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."

tptacek 17y ago
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.
- bfung 17y ago
  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.
  - tptacek 17y ago
    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.
    - johns 17y ago
      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?