Protect Your Site with URL Rewriting | Hacker News Reader

Protect Your Site with URL Rewriting

msdn.microsoft.com

13 pointsrdoherty23 comments

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.

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

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

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. =)

See johns' earlier comment on why it's insecure and kludgy: http://news.ycombinator.com/item?id=706329

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.

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.

??? 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?

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 don't disagree even a little. I'm just pushing back on "here's an example of Microsoft being crazy".

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

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.

True, but the existence of non-www HTTP pages doesn't make the breakage of the rest of the web any better... :)

I don't love this article, and I really don't want to pigeonhole myself into defending it. But one thing to keep in mind before commenting about how psycho it is to obscure URLs to prevent automated attacks is the audience for this article.

This is an article aimed at internal enterprise application developers. The people using ASP.NET to build applications that need to retrofit XSS protections are not YC startups or the next Wikipedia; they're commercial banking applications that normal people are never going to use.

Reply on news.ycombinator.com