Passing IDs between web applications

Question

We have several web applications that create a shopping cart, save it to a database, then redirect to a centralized web application to process and accept payment for the shopping cart. Right now, we are using GUIDs for the shopping cart IDs and passing those GUIDs in the querystring to the payment application. We are using GUIDs so that a user cannot easily guess the shopping cart ID of another user and simply plug that ID into the URL.

Now, using GUIDs in the database is bad for indexing and using GUIDs in the URL does not truly prevent a user from accessing another cart. However, using passing integers around would make it too easy.

What is the best and most secure way to pass the IDs from the individual applications to the centralized payment application?

I know that some people may say, "Who cares if someone else wants to pay for someone else's shopping cart?" However, we have the same concern when passing IDs to the page that displays the receipt and that page includes the customer's name.

Answer 1

Had you thought of POSTing to the central system and passing the values that way? Then they wouldn't be visible in your query string.

Answer 2

If you have to pass the GUID in the querystring, you could encrypt it to make it a little more secure. It will add a little overhead, also, to your processing.

You could also tie the user's cart to a cookie, then the GUID wouldn't be visible in the querystring and would be a little harder to detect (although using fiddler or some other tool like that would show what's being passed up and down).

I'd stick the identifier in a cookie, some other header or, if you have to POST, as a hidden value (like Lazarus suggested). I'd avoid having it on the querystring.

Answer 3

You could pass the ID as an integer along with a "token" which would be a (cryptographically strong) hash of the cart ID and a random secret string. The payment processor would know the secret so it could perform the hash itself and compare to see if it is valid.

For example you can use the following (untested) code to create the token:

public static string GenerateHash(long CartID)
{
    string SourceText = CartID.ToString();
    //Salt the source text (secret)
    SourceText += "5E95C91F7F947BD92ACA2CF81C3ADBD9B563839D85EA69F9DEA5A2DC330D0F50";
    //Create an encoding object to ensure the encoding standard for the source text
    UnicodeEncoding Ue = new UnicodeEncoding();
    //Retrieve a byte array based on the source text
    byte[] ByteSourceText = Ue.GetBytes(SourceText);
    //Instantiate an MD5 Provider object
    System.Security.Cryptography.SHA1CryptoServiceProvider SHA1 = new System.Security.Cryptography.SHA1CryptoServiceProvider();
    //Compute the hash value from the source
    byte[] ByteHash = SHA1.ComputeHash(ByteSourceText);
    //And convert it to String format for return, also modify for URL use
    return Convert.ToBase64String(ByteHash).Replace("=", "").Replace("+", "-").Replace("/", "_");
}

Pass the result of this function, along with your cart ID, since a hash is a one-way function that cannot be reversed. On the payment processor you would call the same function on the passed in cart ID and compare it to the token.

This will prevent tampering with the query string yet allow you to use integers.

Answer 4

I would use methods similar to the Anti Forgery Token in ASP.NET MVC.

http://davidhayden.com/blog/dave/archive/2009/04/29/AntiForgeryTokenInMVCFramework.aspx

EG. In addition to your GUID, save a random id in a cookie and in the db tied to a user. Each time the user makes a http request check that the cookie matches with the database. It would be hard to get both the GUID and cookie correct.