

Protect Your Site with URL Rewriting - rdoherty
http://msdn.microsoft.com/en-us/magazine/dd458793.aspx

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

~~~
tptacek
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
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
??? Doesn't every secure programming book start out with insecure code and
then demonstrate how to properly fix it?

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

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

