5 ms·

Had to submit this, one of the craziest ideas I've heard for 'security'. Because people don't want to bookmark, share or reload their web pages. And if you can

Had to submit this, one of the craziest ideas I've heard for 'security'. Because people don't want to bookmark, share or reload their web pages. And if you can get bad data into a system, it doesn't matter what the URLs are.

petewarden 17y ago
This is classic Microsoft: give up on securing the underlying system and layer kludgy temporary 'fixes' on top that break standards and functionality. Not so much security through obscurity, as security through making the system hard to use for everyone! See also Vista's UAC...
- tptacek 17y ago
  I'm pretty sure you have no idea what you're talking about. Not securing the "underlying system" is not one of Microsoft's problems. No company in the entire industry spends more per line of code shipped or per developer on security than Microsoft; it would not surprise me to find out that Minesweeper got a security architecture review, a line-by-line security code review, and a penetration test before it was last shipped. Your comment added no information. If GUID URLs are "kludgy", explain why they're kludgy. If something about ASP.NET is fundamentally insecure, explain how it's insecure. (I say all this as a devoted Mac user).
  - kirse 17y ago
    I always enjoy when you come into the security threads on HN, call everyone out on their BS and set the record straight. Keep up the good work. =)
  - sp332 17y ago
    See johns' earlier comment on why it's insecure and kludgy: http://news.ycombinator.com/item?id=706329 http://news.ycombinator.com/item?id=706329
    - tptacek 17y ago
      You are citing sample code in an MSDN article to defend an argument that the ASP.NET stack is insecure and kludgy (even if you don't realize it, because you haven't really read the comment thread).
      - sp332 17y ago
        I just misinterpreted what petewarden meant by "underlying stack". I thought he meant the particular website in the article, I see now he meant ASP.NET instead.
tptacek 17y ago
How is this one of the craziest ideas you've heard? Amazon's web services use essentially the same approach, as do countless J2EE, PHP, and Python web applications. I think you're picking on this because it's Microsoft, and because it's written for an audience of Visual Basic programmers.
- johns 17y ago
  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.
  - maukdaddy 17y ago
    ??? 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.
andreyf 17y ago
I think you forgot linking - you know, that things that makes it a world wide web, not a world wide bunch of pages...
- tptacek 17y ago
  Not everything that uses HTTP needs to be part of a "world wide web"; sometimes, a form-based app is just a form-based app, and better that it use HTML and work in Firefox than a Win32-only WPF app.
  - andreyf 17y ago
    True, but the existence of non-www HTTP pages doesn't make the breakage of the rest of the web any better... :)

petewarden 17y ago

This is classic Microsoft: give up on securing the underlying system and layer kludgy temporary 'fixes' on top that break standards and functionality. Not so much security through obscurity, as security through making the system hard to use for everyone! See also Vista's UAC...

tptacek 17y ago
I'm pretty sure you have no idea what you're talking about. Not securing the "underlying system" is not one of Microsoft's problems. No company in the entire industry spends more per line of code shipped or per developer on security than Microsoft; it would not surprise me to find out that Minesweeper got a security architecture review, a line-by-line security code review, and a penetration test before it was last shipped. Your comment added no information. If GUID URLs are "kludgy", explain why they're kludgy. If something about ASP.NET is fundamentally insecure, explain how it's insecure. (I say all this as a devoted Mac user).
- kirse 17y ago
  I always enjoy when you come into the security threads on HN, call everyone out on their BS and set the record straight. Keep up the good work. =)
- sp332 17y ago
  See johns' earlier comment on why it's insecure and kludgy: http://news.ycombinator.com/item?id=706329 http://news.ycombinator.com/item?id=706329
  - tptacek 17y ago
    You are citing sample code in an MSDN article to defend an argument that the ASP.NET stack is insecure and kludgy (even if you don't realize it, because you haven't really read the comment thread).
    - sp332 17y ago
      I just misinterpreted what petewarden meant by "underlying stack". I thought he meant the particular website in the article, I see now he meant ASP.NET instead.

tptacek 17y ago

How is this one of the craziest ideas you've heard? Amazon's web services use essentially the same approach, as do countless J2EE, PHP, and Python web applications. I think you're picking on this because it's Microsoft, and because it's written for an audience of Visual Basic programmers.

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

andreyf 17y ago

I think you forgot linking - you know, that things that makes it a world wide web, not a world wide bunch of pages...

tptacek 17y ago
Not everything that uses HTTP needs to be part of a "world wide web"; sometimes, a form-based app is just a form-based app, and better that it use HTML and work in Firefox than a Win32-only WPF app.
- andreyf 17y ago
  True, but the existence of non-www HTTP pages doesn't make the breakage of the rest of the web any better... :)