ASP - Query string encryption

Author

Query string encryption

the other john

2006-02-17, 6:55 pm

I've been looking for a solution for this and have seen some approaches
but none that seem appropriate for what I'm trying to do. This is what
I need...

I'm trying to encrypt query strings.
For Example...
I want this...
http://whatever.com/?clientID=5
to be something like this...
http://whatever.com/?[encrypted string]

I've seen the 4guysrfromrolla's version. Its fine "but" I don't know
if it would be practical in this case. I would need to encrypt many
urls on a single page and every link on a displayed page would be
pulled from a database. the "rolla" version I came across requires
that a text file be created and key written for each encoded string
everytime the page is called. This doesn't seem that practical to me
because I would be writing files and keys dozens of times everytime the
page is called.

I've also seen aspEncrypt but they want 250 bucks and I was hoping to
avoid this. I also see that .Net has a method for this but I'm only
working with classic at this point.

Is there another method out there?

Thanks!

Dave Anderson

2006-02-17, 6:55 pm

the other john wrote:
> I've been looking for a solution for this and have seen
> some approaches but none that seem appropriate for what
> I'm trying to do.
> This is what I need...
>
> I'm trying to encrypt query strings.

Why bother?

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

the other john

2006-02-17, 6:55 pm

Ok, why reply if you don't have anything to add? Not trying to be rude
but this doesn't help much.

Dave Anderson

2006-02-17, 6:55 pm

the other john wrote:
> Ok, why reply if you don't have anything to add? Not
> trying to be rude but this doesn't help much.

I have plenty to add. But there are few contexts in which it makes sense to
"encrypt" the querystring. Thus the question.

If you explain what your objective is, perhaps someone can suggest an
alternative approach to achieving it.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

the other john

2006-02-17, 6:55 pm

This application is a content manager for web development. It manages
clients, developers, and administrators. Each have their own level of
access. The problem comes in when querying the database. A developer
or client could change the ID's in the querystrings to view projects
not assigned to them. I've always used querystrings to pass the unique
values to retrieve the appropriate data. I want to encrypt the query
strings to avoid this problem.

Dave Anderson

2006-02-17, 6:55 pm

the other john wrote:
> This application is a content manager for web development. It manages
> clients, developers, and administrators. Each have their own level of
> access. The problem comes in when querying the database. A developer
> or client could change the ID's in the querystrings to view projects
> not assigned to them. I've always used querystrings to pass the
> unique values to retrieve the appropriate data. I want to encrypt
> the query strings to avoid this problem.

OK. I think I understand. You want to obfuscate the record keys in lieu of
authentication and privilege checking. This is possible, but it is important
that you realize that obfuscation is not security.

If you are identifying each user, you might want to actually design your
application so it verifies user privileges with every round-trip. I do this
with MOST applications.

But I realize this is not always possible. Some of our apps allow anonymous
submissions (and tracking by the originator). For these, we need what you
are s

ing -- obfuscated keys. And for many of these, we use GUIDs.

Now, you don't mention your database variety, but if it's SQL Server, you
might want to give consideration to GUIDs (SQL Server type:
UNIQUEIDENTIFIER). I find it straightforward to add them to existing tables,
and they are fairly tough to guess outright.

Say, for example, your project table has an identity column [ID], upon which
you JOIN other tables:

SELECT P.*, H.*
FROM Project P
JOIN History H ON (H.ProjectID = P.ID)
WHERE P.ID = 12345

Adding a GUID would barely change this query:

SELECT P.*, H.*
FROM Project P
JOIN History H ON (H.ProjectID = P.ID)
WHERE P.GUID = 'A4C187AD-92AC-478F-9AED-9B74AEB5CB60'

Notice that the GUID need only be part of the root (project) node. ID
becomes a "private property" of the project -- no user ever needs to know
it, but as an INT, it is far better suited for being part of a primary key
than a GUID is. More importantly, your existing relationships are not
changed by adding the GUID.

If this approach interests you, I can expand a little on the topic.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

the other john

2006-02-17, 9:55 pm

This is much more helpful, thank you. Unfortunately, this is for
Access. I worked with SQL Server before but I don't know what a GUID
is (although I am interested for future reference). I had thought of
figuring out a way to verify the user each time but this project is
falling behind and it's complexity growing and the query string
encryption was supposed to lighten this load, ugh.

Is there a way to do this with access in a similar way?

Thanks again.

the other john

2006-02-20, 6:55 pm

I should have asked earlier...what other way would you suggest other
than using querystring encryption? Form collecton doesn't seem
practical and I wouldn't know how to implement it in this case either.

Thanks again.

Dave Anderson

2006-02-20, 6:55 pm

the other john wrote:
> I should have asked earlier...what other way would you suggest
> other than using querystring encryption? Form collecton doesn't
> seem practical and I wouldn't know how to implement it in this
> case either.

Please note that "querystring encryption" is a false term. If the
"encryption" has to be done on the client, then it's not encryption (unless
you want to write your own key exchange implementation). You are looking for
obfuscation.

I suggested GUIDs because they are easy to implement and tough to guess.
They may still be an option for you:
http://www.aspfaq.com/show.asp?id=2108

Presumably you could then store them as text.

Another option is to generate "random" keys when you create the records.
These can be numeric or alphabetic, but I suggest you avoid integers. I say
"random" with quotes because (1) truly random generators are only
theoretically possible, and more imprtantly, (2) you will have to test for
uniqueness, which automatically voids the randomness of the generator.

I'm sure there are other techniques, but you seem to be looking for a quick
fix.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

Patrice

2006-02-20, 6:55 pm

Another approach would be to let the user change the value but implement
access checking when reading the record. If he is not allowed he shouldn't
be able to access this record.

With the encryption approach, one could send a shortcut to someone else and
this other person could be able to gain access to the protected record. IMO
it's best to implement first security at the recored read level....

--
Patrice

"the other john" <kinane3@yahoo.com> a écrit dans le message de
news:1140212415.556398.155810@g44g2000cwa.googlegroups.com...
> This application is a content manager for web development. It manages
> clients, developers, and administrators. Each have their own level of
> access. The problem comes in when querying the database. A developer
> or client could change the ID's in the querystrings to view projects
> not assigned to them. I've always used querystrings to pass the unique
> values to retrieve the appropriate data. I want to encrypt the query
> strings to avoid this problem.
>

the other john

2006-02-20, 6:55 pm

at the moment, yes, I am looking for a quick fix since the cost of the
project wasn't intended to go as far as it already has. However, I am
interested in better solutions for future reference.

I'm trying to envision a solution that checks for what the user has
access to at each page load. Would this in itself be a recordset that
is referred to at every page view? Is that what you meant by record
read level? It seems simple enough in concept but each time I think
about it it gets more complicated.

Thanks again all.

John

Patrice

2006-02-21, 3:55 am

I meant that when you read a recordset from the DB :
- for now, it looks like you are reading the row just based on the key
provided in the querystring. As a result if someone changes the key he can
get at any record he wants
- if the query select the row based on the key *and* on application
permission, he won't get the record if he is not allowed to see it

--
Patrice

"the other john" <kinane3@yahoo.com> a écrit dans le message de
news:1140461384.445337.270840@g47g2000cwa.googlegroups.com...
> at the moment, yes, I am looking for a quick fix since the cost of the
> project wasn't intended to go as far as it already has. However, I am
> interested in better solutions for future reference.
>
> I'm trying to envision a solution that checks for what the user has
> access to at each page load. Would this in itself be a recordset that
> is referred to at every page view? Is that what you meant by record
> read level? It seems simple enough in concept but each time I think
> about it it gets more complicated.
>
> Thanks again all.
>
> John
>

Sponsored Links