Guids, QueryStrings and Authentication

I have a number of locations in a number of applications I have built where a page accepts a QueryString in the following format: http://localhost/MySite.aspx?ID=ab1cbabe-42e2-4d15-ab11-17534b82开发者_如何学Go9381

These pages will then take the query string, attempt to parse it and display the data that matches the guid using a database call with strongly typed values.

Example:

Guid value;
if (Guid.TryParse(Request.QueryString["ID"], out value))
{
    SomeControl.Datasource = DatabaseCall(value);
    SomeControl.Databind();
}

What this obviously means is that any user (provided they have the guid for the data) can technically access any other users data. Obviously predicting guids is next to an impossibility but I'm still uneasy about it.

How does everyone else deal with this problem? Is there a "correct" way? Is it even worth worrying about?

In various circumstances it absolutely is worth worrying about.

1. People tend to post or email URIs without stripping away the query strings
2. Most browsers store the whole uri including the query string in a history
3. Most browsers even offer autocomplete in the address bar which lets you try through already visited resources
4. The http request can be intercepted pretty much anywhere on its way from client to server, exposing the query string

I'd recommend some kind of user-based authentication mechanism like asp.net's membership provider.

In case you already are using some authentication, linking resource guids to their respective user ids in an association table might do the trick.

You answered your own question: "Obviously predicting guids is next to an impossibility"

However, the proper way to implement user access, is to build and manage an ACL. You can't simply rely on a unique string for that, because even if users don't guess the string, an attacker can still sniff the traffic and reuse the GUIDs they found.

I agree with @Laurent.

But - it depends on your type of business. For extreme security-related contexts such as banking, money transactions, sensitive personal data etc., I would go to an encrypted cookie, or simple - a unique key that is passed in the query string (as you asked about), but not a guid but something far longer (just make sure it's randomness is fairly hard to predict), along with a background task on the server that invalidates "tokens" that are older than X minutes, to mitigate the risk of stealing URLs.

Consider resorting to some standard mechanism such as ASP.NET Membership.