[Esapi-user] Is this a safe way to do a .NET Server Redirects? (and deal with A10: Unvalidated Redirects and Forwards)

Kevin W. Wall kevin.w.wall at gmail.com
Sat Mar 9 18:47:08 UTC 2013


Probably a bad idea to cross post to so many lists. I think I'm subscribed to a
few others, but I'm only going to respond on the ESAPI-Users list. Many users
first reaction is to Reply-All and not trim the Cc: list so that then they have
to deal with the unexpected bounces. Unfortunately mailing lists are
not like newsgroups where newsgroup readers can simply not post your
replies to groups that you've are currently subscribed to; MUAs don't
behave that way.

On Sat, Mar 9, 2013 at 5:41 AM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
> Question details here:
> http://blog.diniscruz.com/2013/03/is-this-safe-way-to-do-net-server.html
> The interesting question is at the end of the post: On that topic, is there
> a list of Use Cases that this function should pass? (in order to make it as
> 'secure'?)

Well, since you seem to only be concerned about doing this to redirect
back an unauthenticated page back to their original page after they've
been redirected to the login page and have successfully authenticated,
you might consider checking the LoginReferer parameter check as early
as possible to see if the user is actually not presently authenticated.
If they are, you might consider such a use suspect and reject it. Under
normal circumstances, you would never expect a user to get redirected
to your login page with a LoginReferer parameter set to something while
they are currently authenticated. (I imagine that you have it configured if
one were to bookmark your login page, LoginReferer would either be
absent or empty.)

> This is a good example of why I like the idea of an ESTAPI since what I
> really need here (as a developer) is a set of unit-tests / use-cases that I
> can run my code against (on dev and CI) in order to make sure it is (and
> stays) secure.

Unfortunately, I don't even think we have the beginnings of such an ESTAPI.
AFAIK, we haven't even agreed on any detailed relevant use cases that we
could use as a first step to develop such tests. But that's not a topic for
the ESAPI-Users list. (The ESAPI-Dev list, perhaps?)

> Questions:
> Is there something on ESAPI Java code that I can look at? (for example it's
> Unit Tests for their redirect modules?)
> Is there a good example on ESAPI .Net?
> Are there UnitTests that show MS' AntiXss in action in cases like this?
> Other good resources?

My thoughts are two-fold.  The first is, if you are going to have a LoginReferer
query parameter that gets added as a result of redirecting an unauthenticated
user to your login page, why not have your application actually encrypt the
URL with a secret key that only your ASP.NET cluster shares? I've worked with
others to do this with ESAPI Java's CryptoToken class which makes it pretty
easy. (Of course, you'd be setting the user to something like "<anonymous>"
or whatever since they would not be authenticated at that point.) That
also allows
you to set a short timeout to decrease the probability that if a valid request
was stolen somehow, it is much less likely to be successfully replayed.
I've not looked at the ESAPI .NET's crypto, but it definitely will not have
CryptoToken as that was added in ESAPI 2.0 (Java). What I cannot tell
you is whether the ESAPI .NET's crypto is as badly broken as was
ESAPI 1.4 (Java). I suspect that it is because I think it was modeled
on ESAPI 1.4, but if you can find a .NET assembly that supports an
.authenticated encryption cipher mode such as GCM or CCM, it's
fairly easy to write and get something safe. (I've not looked since 5 yrs
ago, but there weren't any then. There are some that are in C, such as
NaCL that you could wrap in some managed C++ code and use, but
that might be a major undertaking.)

My second line of thought is why bother to use a query parameter for
this at all?  Instead, why not store LoginReferer in your ASP.NET
session? Sure, you probably assign a new ASP.NET session
(a new ASPSESSIONID cookie) upon successful login, I think that
you should still have access to the old session up until that point,
so as long as you extract it and validate it before hand, I think it should
be possible. If it is handled that way than you've just raised the bar
on what an adversary needs to do to manipulate it.

Personally, I would recommend the second approach unless something
else, such as a web access management system such as RSA Access
Manager or CA SiteMinder, etc., are forcing you to use make LoginReferer
a query parameter. The solution certainly is much easier especially if
you don't have all the crypto supporting framework pieces in place.

Anyhow, hope that helps some.
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein

More information about the Esapi-user mailing list