ASP.NET: Obfuscating the Querystring

Some time ago I answered somebody's post on the MS C# newsgroup. This person was trying to "pass a connection" to another ASP.NET application from a redirect or a link and couldn't figure out how to do it. Of course, you wouldn't be able to pass the connection object itself (nor should you even try) but you could put the connection string to create it on the QueryString, grab it back out in the Page_Load event of the receiving page, and then simply re-create the same connection.

That was the essence of my suggestion - put the connection string on the QueryString.

Shortly thereafter Steve Orr, whose work I respect, responded that putting a connection
string on the querystring posed a substantial security risk, which is correct.
So what I'm about to offer here is a nice, compact way to encapsulate the QueryString
in ASP.NET as an object that makes it much easier to manipulate, along with some
nice code that will perform ASCII-to-HEX scrambling on both the names -- and
the values -- of everything on the querystring. Actually you probably could never
get an unencrypted connection string on the querystring anyway, it contains illegal
"=" characters, so you'd have no choice but to mangle it in some way.
(Similarly, we cannot use Base64 encoding since a Base64 encoded string ends
with one or two equals signs.)

This is not "encryption" - it's only scrambling or "obfuscation" - which is typically all you need
to keep your "stuff" away from prying eyes. If you truly need strong
encryption, my suggestion is -- don't use the querystring at all; find another
way. Of course, you can add to this, for example doing TRIPLE-DES encryption
before performing the ASCI-To-HEX, and the reverse for decrypting, if you wanted
to do "overkill". But the bottom line is, it's best not to put sensitive
data on the querystring at all -- there are other ways to pass the data.
First, I make use of Bobby DeRosa's QueryString class which is shown here virtually
unchanged from his original post:

What the above gives us is an easy way to work with the Querystring as a true "object"
rather than having to write what I like to refer to as "BS code" just
to get items and so on. For example, with a real object encapsulating the Querystring,
we can write code like this:

Tell me that isn't a lot easier to work with! You can see the call the encryption
utility passes an instance of the entire Querystring object, and receives back
a new one, encrypted - both names and values. All we need to do is call the ToString()
method and add it to the base redirect URL. Now, on the receiving end:

I experimented with XOR, ROT13, ROT39 and ASCII-to-Hex, which is the method I finally
settled on. Since this method doesn't require any UrlEncoding normalization,
that part of the QueryString class has been commented out. The net result of
all this is that this QueryString (which would not even pass as it contains illegal
characters):

You can see the two static methods EncryptQuerystring and DecryptQuerystring which
accept and return Querystring objects. So now, if you have a need to scramble
your QueryStrings for "basic security", this becomes an easy way to
handle it. A nice side benefit of this is that now you can put whatever you want
into a querystring item - spaces, semicolons, slashes, equals signs -- you name
it, and it will be faithfully reproduced on the receiving end.

N.B. Thanks to commenters Steve and Richard on the original of this article for their
coding suggestions, both of which have been incorporated into the downloadable
source code below. And - If you truly want secure transmission of items from
one page to another, DO NOT put them on the querystring!