Hiding a queryString in an ASP.NET Webapplication

Question

I have two webapplication, one is a simple authenticationsite which can authenticate the logged in user and redirects him then to another site.

Therefore I have to pass ther userId (GUID) to the second application. Currently this is done via the URL but i would like to hide this id.

Has anybody an idea how to do this properly?

[EDIT]: I can't use the Session because of the ApplicationBoundaries (2 different Servers)

Answer 1

Pass the GUID through a session, best way.

http://www.w3schools.com/ASP/asp_sessions.asp

OR, since it's 2 different servers, pass the information by POST method:

http://www.w3schools.com/aspnet/aspnet_forms.asp

The other possibility is to store the session state in a database on the local server, and remotely access that database from the other server to see if the user has successfully logged in and within session timelimit.

With that in mind, you can do the entire authentication remotely as well. Remotely connect to the local database from the remote server and check the login credentials from there...that way you will be able to store the session and/or cookie on the remote server.

I would recommend AGAINST the hidden field proposition, as it completely counteracts what you are trying to do! You are trying to hide the GUID in the URL but posting the same information in your HTML code! This is not the way to do it.

Best choice is the database option, or if not possible, then use HTTP POST.

Answer 2

Use session variables or HTTP POST instead of HTTP GET.

Answer 3

If the servers have a common domain name, you can use a cookie.

EDIT: Cookies will just hide the ID visually, it is still accessible. Same with hidden fields or using POST rather than GET. So if the ID is confidental and you want to avoid to send it over the network unencrypted, you need a different approach.

A solution could be to encrypt the ID on the auth server with a key which is shared by the servers. Another solution could be to generate a random GUID on the auth server, and then let the auth server directly inform the other server (over SSL) which ID the GUID corresponds to.

Answer 4

Instead of passing it via a query string you should create a hidden form field with its value and then post to your 2nd page, which can then grab the posted value and it will be hidden from the user.

Answer 5

This sounds like a tricky situation. There are however several options you can use but it all depends on what your application does.

Let's call WebApp1 your authenticate site, and WebApp2 your distination site once authenticated.

Can WebApp2 not call WebApp1 behind the scenes? (Services)

THe problem with passing this Guid between applications is it's going through clear text, and considering it's a user id, if anyone manages to intercept this they will have access to WebApp2 for life. Whether you pass it in a querystring or form variable, it's still vulnerable.

If you can't use WebApp2 to query WebApp1, you should consider WebApp1 creating a temporary Guid that expires. That would be much safer long term, but as it's clear text is still susceptible to attack. The 2 web apps will also need access to the same data store.

Ultimately, i think the AUthentication Site should be a service which WebApp2 can consume. Users should login through WebApp2, which will call WebApp1 securely for authentication. WebApp2 can then manage it's own session.

Answer 6

If you can't use cookies because it's cross domain then encrypt it, with a nonce.

Setup a shared secret/key between the two servers; send the encrypted GUID and nonce combination to the second server. Unencrypt, check the nonce hasn't already been used (to stop reply attacks), then use the unencrypted GUID.

If you want to be extra tricky have a web service on app1 where it can check the nonce was actually issued (at this point you're heading towards WSTrust and a single sign-on solution, which generally solve what you're trying to do)

Even with cookies, as they're easily edited/faked, you should have some form of checking.

Answer 7

You have two ASP.NET web applications, and one application does nothing but authenticate a user?

this sounds like a job for....

Web Services!

Create a new web service on the authentication app (They are the .asmx extension), and add a single method that takes in the user and password etc, and returns authentication info.

Then import the WSDL on your 2nd app, and call the 1st app like it was a method. It will simplify your code, and fix your issue.

An Example:

AuthenticateUserService.asmx goes on the Authentication app:

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class AuthenticateUserService : System.Web.Services.WebService 
{   
    [WebMethod]
    public bool AuthenticateUser(string username, string passhash) 
    {
        // Fake authentication for the example
        return (username == "jon" && passhash == "SomeHashedValueOfFoobar");
    }

}

Once this is setup, fire up your main app, and right click the project and click "Add Web Reference".

Enter the url to the asmx on the authentication app, and Visual Studio will discover it and create a proxy class.

Once that is done, we can call that method like it was a local method in our main app:

protected void Page_Load(object sender, EventArgs e)
{
    // Now we can easily authenticate user in our code
    AuthenticateUserService authenticationProxy = 
         new AuthenticateUserService();
    bool isUserAuthenticated = 
         authenticationProxy.AuthenticateUser("jon", SomeHashMethod("foobar"));
}

So, what does this really do?

It eliminates the client from the authentication process.

Your current process:

• Client Enters credentials to AppA
• AppA redirects the client to AppB
• AppB redirects the client back to AppA if the credentials match.

Is replaced with a server side SOAP call between AppA and AppB. Now its like this:

• Client enters credentials in AppA
• AppA asks AppB if they are good
• AppA serves proper content to the client.