What is it? How does it work? How to use it? An example Download

What is it?

CGISecure is a means of granting access to password-protected content on the internet, based on session keys. Given a password and a request file, CGISecure will check if the password supplied grants access to that file. If so, it will create a random session key, and return the requested content. Using CGISecure, this key can also be used to access content linked to the requested file. So, in effect, this system can be used to access a complete password protected part of a website.

How it works

As you may have guessed by the name, CGISecure is CGI-driven. To use it, simply put the cs.exe program on your site's /cgi-bin/ directory (or a subdirectory thereof).
All files in /cgi-bin/ are viewed as executables, so when a client requests a file from that directory, the server attempts to execute that file and return its output. So if one would put a .jpg picture in that directory, requesting it from internet will result in an internal server error; a picture file cannot be properly executed by a server.
That is what CGISecure tends to exploit; a client from internet cannot directly request non-CGI files, however, a CGI program on that same server can. So the idea is simple: let cs.exe return the stored content in a /cgi-bin/ directory.
Of course this is a sloppy hack and should be considered a bad idea, but it was fun to play around with.
As said before, CGISecure is based on session keys. To get such a key, one has to execute a post action on cs.exe/post, containing a password and a link. The link refers to the initial file requested. After sending the password, it is transformed into a key. This key is compared to the key stored in link.cgs -- which is a kind of password file. If they match, a random session key is created and sent back to the client. This random key is also stored server-side in the file access.cgs, together with the login time and the initial link file.
Now about some more interesting aspects of this program. The file link.cgs does not only store the private keys, but also which files can also be accessed by a key used to access a given initial link. For example, if you have a private key for an initial link named "index", you can add a dependency for "picture.jpg" to "index"; as such, the key used for access to "index" can also be used to access "picture.jpg".

How to use it

cs.exe supports four different base operations: "getHTML", "getfile", "showfile", and "getpic". These four actions naturally all require a link of what to get or show. "getHTML" will return a (parsed) html file. "getfile" will return a file-stream, which can be downloaded. "showfile" will return the file as plain (viewable) text. "showpic" will return a picture.
Additionally, with all actions, cs.exe requires a session key to check if the client has access to that file.
The precise makeup of a request is:
With these actions you could let an initial link refer to an index-html file, in which you could link to different content (such as pictures). However, to gain access to that different content you'll need the session key by which the initial link was opened; this is done via the "<?key?>"-tag. Upon request via cs.exe any instance of "<?key?>" is automatically replaced by the current session key.
Using these four simple actions one can easily make a password-protected site. Via link.cgs you can give different file-permissions to different initial links. In this regard, initial links can be refered to as users.

An example

Let us create a password protected html file which contains links to three difference pictures (01, 02, and 03.jpg). We put these three images in our server's /cgi-bin/ directory. We then write the index.html file which links to these three pictures. In all simplicity, it could look like this:
<title>CGI Picture Test</title>
<a href="cs.exe?getpic&01.jpg&<?key?>">Picture 1</a><br>
<a href="cs.exe?getpic&02.jpg&<?key?>">Picture 2</a><br>
<a href="cs.exe?getpic&03.jpg&<?key?>">Picture 3</a><br>
We name this file index.html in put it in our /cgi-bin/ directory.
We note again that direct linking to this file or any of the pictures via the internet will result in a internal server error, and as such are inaccessable for unauthorized users.
Also note that when this file is requested by CGISecure, the <?key?>-tag is replaced with the current session key.
Now we need a page in which we can enter a password to gain access to this index.html file. Such a page, again in a simple form, could look like this:
<title>Password Required</title>
<body bgColor=black text=white>
<form method=POST action="">
Password: <INPUT TYPE="password" name=password><br>
<INPUT TYPE="hidden" name=link value="index.html"><br>
<INPUT TYPE="submit" value="Go">
Note that we tell cs.exe to link to "index.html" via the hidden input type "link". Drop this file in /htdocs/ (in case you're using apache); you'll want this file to be publically accessable.
In this example, is the used server. Note that the use of SSL (https://) is not required, and in conjunction with session keys is a little overprotective (unless you expect someone to spy every bit of your incoming internet traffic). That is why CGISecure will automatically change https:// in http://, after password verification ofcourse.
The only thing left to do is to set our password. Let's say our password is "dutchhaven". We now need to create a private key out of this password. This is done with the "coder"-program (included with the package). Just type in dutchhaven and click on "make key", and you'll get a rather large key. Just copy paste that into the link.cgs file, together with the picture dependencies, like this:
Note that the auto-generated password-based key is actually quite weak and can easily be reverse-engineered. The last three lines link the pictures to the index.html file, and the index.html file needs a password which is checked by using the key stored in the first line. Now we're all set.


Latest version: [zip]. Includes example files.
Changelog: [txt]
For questions, comments, bugs, etc.: email me.

By A.N. Yzelman (2005), webmaster@trancethrust.nl, www.trancethrust.nl