When is it OK to intentionally obfuscate URLs?

Question

Having friendly URLs is generally a good thing. However, there are sometimes when it seems like a bad idea. What is your rule of thumb?

For instance, consider a situation where I want to show a Registration Success page. I want all of the underlying logic to be the same. However, depending on how they registered, I may want to display a different message for someone who registered under a certain type of role.

Here are a few, off-the-cuff examples of "hackable" (as described in link) URLs:

• http://www.example.com/RegistrationSuccess.aspx?IsCertainRole=true
• http://www.example.com/RegistrationSuccess.aspx?role=CertainRole
• http://www.example.com/RegistrationSuccess.aspx?r=2876

All of these seem bad since I don't want the URLs to be discoverable. On the other hand, I hate to do something more complex just to modify the success message slightly.

How would you handle this?

Answer 1

With a post submission?

If you don't want information in the URL, don't put it in the URL.

It's not always easy to do...

Answer 2

I would say that pages that you want to be easily indexed by the search engines use URL Routing. This includes high traffic pages.

For other pages where the users will only visit few times a month or year you can leave those to be normal urls.

Answer 3

If you must absolutely use the URL for private/personalized data, you'd probably be better off generating a random unique identifier on the server and using that in your URL. Kind of like confirmation e-mails where you have to click a link.

Otherwise, if there's any other way to not include data in the URL, you shouldn't. In the case of a successful registration, either the person just registered and you should be in a current session, or you should require them to login before they see the customized page.

Answer 4

Why not make "registration success" message be a last step, but not change pages?

You can use Ajax or Server.Transfer() to do that.

Answer 5

You can either POST the data, or, if that's not an option, set the value in a Session variable and then read the value in the success page. The actual complexity of code using the Session is about the same as using the query string.

Answer 6

Bear in mind that obfuscating URLs is NOT a security measure. You should never trust outside input - filter, sanitize and implement restrictive logic. No matter how clever you believe your obfuscation scheme to be, people have cracked much more complicated security schemes with relative ease.

As a general rule of thumb - there is no good reason to obfuscate URLs intentionally. Use URLs to communicate read operations (a path to a resource). Use POST requests to communicate write operations (adding/modifying data). If a user isn't supposed to be able to do something through the URL, it should be regulated server side and through the request method.

Answer 7

You could make some sort of checksum or hash on the querystring items, so if they mess around with the URL, the checksum fails and it kicks them out to the main page.

Answer 8

I could check from a whitelist of referring URLs so that they can't just type in a different URL. That might eliminate obvious "hack" from a passerby.

(Obviously, you can get around this if you're a nerd.)

Answer 9

Ok, if you don't think this is a security issue since you are only displaying a different message, then why do you care if its hackable or not?

Most users won't wouldn't notice the url is editable, so why obfuscate? The "elite hackers" will get a slightly different message, big deal.

The general answer to, "Should I obfuscate...?" is no. If its for security, hell no, otherwise why are you obfuscating? Most likely, you are wasting time.

Answer 10

URL's are for uniquely referencing content. When the contents are the results of a process that involves several steps of dialogue, these contents can't really have a URL, because the URL does not reproduce the process.

I would forward them to RegistrationSuccess.aspx and present contents there based on the state of the session.

If somebody comes to that URL without the suitable session state, I would forward them to the front page after 5 seconds of looking at a friendly message explaining that there is nothing to see.

A better choice yet, may be to forward them to MyRegistration.aspx which is something they would perhaps like to make a favourite out of. Coming from the Registration process, it may have a box explaining that they have successfully registered. If they not coming there from the Registration process, this box is not presented. The rest of the page is the summary of all earlier Registration processes for that user.