Validate your Redirects!

I usually keep an eye on what my web applications are doing every now and then. Recently I noticed some really strange redirects being fired from one of my older projects. Like redirects to specific IP adresses or curious subdomains, rather traditional addresses for e.g. phishing attacks.

After checking my redirect logic the problem was immediately clear, I didn’t validate my redirects in any way, lazy me. The following code is offers actually a great way for people to use your brand/domain for redirects to spam sites or even phishing sites:

string RedirctURL = Request.QueryString["r"].ToString();

Now someone could easily drop his URL into the QueryString: So what you should do is, check if the input really belongs to your site or is something you really want to redirect to.

If you only redirect to internal sites you can just check the string for a double slash “//”, if it occurs, deny the redirect. If you also redirect to external sites you have to use a database and save all permitted redirect URLs in there.

Also, don’t be tricked by using System.URI.AbsolutePath, because Firefox and IE will transform an invalid URL to a valid URL:

// Returns "//" which will work in FireFox and IE!
Uri link1 = new Uri("");

As you probably know you should always validate external inputs, don’t be lazy or you will be sorry later..


#1 Mowali on 10.24.07 at 3:52 pm

Great article!
I came across this page when I was investigating a way to proof/check/validate our domain redirections.
Currently, our dns box points to a .cs file that controls the mapping between old and new domains.
The code checks for the name of the host and points it to the appropriate location through hundreds of “switch – case” statements. Everytime we get a request of a domain redirect, we have to search if both domains (the old and the new) exist already in list; remove it; and then add another case statement for the new redirect. Even though the process is simple and not so much erroneous, I feel that there is a much better way to do that, but know none.
Do you have any suggestions?
thank you!

#2 andreas.kraus on 10.25.07 at 10:14 am

Hello Mowali,

well, you should probably put that stuff into a database OR XML File as it’s way easier to maintain there.


Leave a Comment