Mads Kristensen

My personal blog about everything tech

Today, I was playing around with HTTP request headers and for some reason started thinking about how limited information they provide about the requesting browser. All they really provide is the user agent string which provide very little information about the visitors platform, and that’s about it. If they also provided screen resolution and available browser window real estate, it would start being useful for other scenarios than we are used to.

Then I started thinking about a way to provide ASP.NET web applications with data retrieved from the browser without interfering with the browsing experience. I found that the only way to get client information from JavaScript transferred to server-side variables is to do redirection, but that is not acceptable. Well, at least I thought. It is actually possible to do redirections without the browser registers it in its history so the back button would act as nothing happened.

This means that it should be possible to retrieve the information in a way that is totally transparent to the visitor. In other words, the website appear to act 100% as usual. If you don't believe me, read on and I'll tell you how it's done.

If it is using JavaScript to gather the information it also means that all information you can possibly retrieve from JavaScript can be transferred to the server. In this version I've implemented the properties you can see in the image above. It is very easy to add more. The code comments tells how.

How it works

To do the trick we need an HttpModule and HttpHandler. The module’s job is to expose the client-side variables to the ASP.NET code while the HttpHandler fills them with data from the browser.

At every request to an .aspx page the module checks if the variables have been set for the requesting visitor. If the page is the first one the visitor hits, the module write a small JavaScript to the <head> tag that collects the information we need and does a silent redirection to the HttpHandler. The handler registers the information sent from the JavaScript and stores it in session variables. Afterwards it redirects back to the original requested page without the visitor noticing any redirection has taken place.

Before you think it sounds too complex, let me assure you that it is very simple. Not only is it simple, it is also plug ‘n play so you can easily implement it into any existing web application – no code required. I've tested it in IE 7, Firefox 2 and Opera 9 all on Windows and it works perfectly. This might be the coolest thing I've ever developed.

Implementation

Download the ClientStats.cs below and put it in the App_Code folder of your website. Then add the following lines to the web.config’s <system.web> section:

< httpModules >

  < add type = " ClientStats " name = " ClientStats " />

</ httpModules >

< httpHandlers >

  < add verb = " * " path = " *clientstats.aspx " type = " ClientHandler " />

</ httpHandlers >

That is all there is needed to gain access to the properties of the ClientStats module.

Download

ClientStats.zip (1,85 KB)

URL parameters or query strings are often used to carry information that can be used by hackers to do identity theft or other unpleasant things. Consider the URL example.com/?user=123&account=456 and then imaging what a hacker could do with it. Security or not, sometimes you just don’t want the visitors to see all the query strings for whatever reason.

In those cases it would be nice if we could encrypt the entire query string so it wouldn’t carry any readable information. The problem with one big encrypted query string is that we would break all the code that referenced the query. Code like Request.QueryString["user"] would no longer work, but as usual ASP.NET has the answer to that problem.

What we need is an HttpModule that can turn the encrypted query string into a normal readable one, so that we can still use our old logic like Request.QueryString["user"]. In other words, we want the user to see this

?enc=VXzal017xHwKKPolDWQJoLACDqQ0fE//wGkgvRTdG/GgXIBDd1

while your code sees this

?user=123&account=456.

The HttpModule

The module we need for this task must be able to do a few simple things. It must be able to encrypt the regular query string so that all your current links will automatically be encrypted. It must also be able to decrypt it again so that you can write the code as you normally would. It must also provide a method for encrypting a regular query string if you don’t want to use automatic encryption.

The most important feature of the module is to make it totally plug ‘n play. You should be able to apply the module to any existing website and automatically have query string encryption and decryption without changing any of your code.

Implementation

Download the QueryStringModule.cs below and put it in the App_Code folder of your website. Then add the following lines to the web.config’s <system.web> section:

< httpModules >

  < add type = " QueryStringModule " name = " QueryStringModule " />

</ httpModules >

Because automatic encryption is not always desirable the module has a comment that tells you how to turn it off. The module is well commented and should be easy to modify for any ASP.NET developer.

Example

You can encrypt query strings by using the Encrypt() method of the module from any web page or user control.

string query = QueryStringModule .Encrypt( "user=123&account=456" );

Then just add the encrypted query string to the links that need encryption. You don't need to use the method if you use automatic encryption.

Download

QueryStringModule.zip (1,55 KB)