I posted a message a few days ago to comp.lang.java.programmer
but I didn't get any replies so I try here, I hope it's not
too much offtopic...

It's about a technique I would call "URL signing" that is really
easy to implement on any Java Web application server using a
"clean" design (like, amongst other things, having every single
request going through a controller firt, then getting dispatched).

But it should be easy to implement on a lot of other different
Web servers.

This technique works, and it works pretty well. It is currently
in use on a production server. What I would like to know is what
is the name of this technique and where/who described it / used
it before.

It is really the first thing I thought of when my client asked
me to protect about the more common Web server vulnerabilities,
I am surprised that I cannot find any informations regarding this
technique on the Net (I googled and groups.googled...).

Below is the message I posted to comp.lang.java.programmer...

Hi all,

To secure the WebApp server of one of my client who was
really concerned about various security issues, I devised
a nice cute little "hack" which I would call "URL signing".

Every single request goes to a front controller servlet
which then dispatch to the correct jsp page (after the
business logic has prepared all the results bean).

Every single link in any of the jsp page transmitted to
the client is generated with a checksum that act as a
signature for the URL, like this (this example is not
precisely how I did it, it's just to show how it works) :

http://somesite.com/dispatch?act=multi&resultSet=9931578&pageNumber=2...

If a user tries to modify a single character in the URL
from his browser, then the front controller servlet will
dispatch to a special page indicating that URL has been
"faked" and fill the logs accordingly.

In a way it is "overkill" when using a Java-only WebApp
server (which is inherently imune to buffer overflow and
I hardly imagine some Java WebApp programmer allowing SQL
injection in the URL :)

But, still, it's a nice additionnal layer of protection.

Of course, for POSTed request it's different : the
checksum still applies (the way I did it), but only on
the parameters that the user can not modify.

The other parameters are then checked for validity too,
using the "normal way".

Then again, the way I designed the WebApp, not a single
of the "sensitive" page (page doing query on sensitive
datas) can be accessed using POST, but only using GETs.

So what this technique bring is : 100% protection for
every single GET request and partial protection for
POST requests...

The partial protection for POST is a really good safety
net : imagine you have an hidden form field with the
value "admin=no" (I wouldn't encourage anyone to show such
an obvious field with such an obvious name/meaning in a URL
though), well... If the URL is signed, the hypothetical
attacker simply cannot change it to "admin=yes"...

I don't advocate on relying on this technique alone to
secure a Web server, but I think it's a nice *additionnal*
layer of protection.

Have you ever heard of a term coined to describe this ? Have
you a ever heard of a Web server (Java or other, Open Source
or commercial, etc.) doing anything similar ? Any links ?

Thanks for comments and excuse my "french",

 Lonedroid

I haven't heard of the technique but it sounds good.

How do you implement the checksum? If you have a static checksum function
(that doesn't add random data or time data to the url) it might cause a
security-problem. In this case it shouldn't be to hard for an attacker to
reproduce your checksum function by looking at the checksums for different
links in your HTML-code and use it to modify the URLs and corresponding
checkskums.

/Erik

On 14 Sep 2003, Lone Droid wrote: