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.
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.
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."
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?
Actually, I wasn't picking on it because it's MS, I'm picking on it because it breaks bookmarking, hyperlinking (leave a page open long enough and links stop working), sharing links and reloading pages.
It also avoids the real solution of simply validating and escaping user-entered data, a much more common and secure method of preventing XSS exploits.
Again: it breaks those things overtly and deliberately, for applications that don't care about those things.
We need to snap out of the meme that internal enteprise apps are built to the same community standards as Wikipedia and Amazon Web Services. A lot of internal apps are just HTML forms hooked up to databases, replacing ancient VB MFC applications that only run on Windows. Stop penalizing VB developers for trying to get their stuff working in a browser without exposing all their data.
Except that there are better ways to accomplish those goals AND get the benefits of a web app.
I don't fault any enterprise devs for trying to get stuff working and I understand they have a different set of working requirements than someone working on a consumer web app. I do fault MS for putting out "guidance" like this that will just be a waste of resources and a maintenance nightmare for corporate devs that don't know any better.
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.
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).
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.
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.
And if you can get bad data into a system, it doesn't matter what the URLs are.