The full Bernie story: http://www.youtube.com/watch?v=b7AiMoOSxlk

It is very unpleasant to have a website mugged, or “hacked”, for no reason at all but the display of the “signatures” of the abusers.
After all these years, here are some tips.

(1)

If you have an ASP.NET web.config global file, yet the system says it can NOT find a valid web.config for a particular application, it might be because of wrong permissions on that app’s file system containing folder.

Since I run IIS6, this page was helpful:

http://support.microsoft.com/kb/317955/

It basically says: “add the NETWORK SERVICE user to the app’s folder”.

Indeed, every .NET app folder must allow the “NETWORK SERVICE” user with the permissions:
- read
- read and execute
- list folder contents

(2)

In IIS6 the user IUSR_TEMPLATE represents an anonymous web visitor and so must be available for all resources to be made public on the WWW.

Generally, this user should only have READ permits and nothing else, for all resources.

If some particular folders require writing, give this user READ and WRITE permits, but *never* WRITE and EXECUTE.

Ideally, the WRITE permit should only be given to out-of-reach-of-the-web-server folders, meaning locations that are nowhere in the tree being made public by IIS, Apache or whatever the http server. But this isn’t always possible: most Content Management Systems (CMSs) will require at least one writable public folder, for example to where bloggers can upload pictures – just follow the minimal approach and the *never* WRITE and EXECUTE rule.

(3)

For read-only web presences, if you strictly follow the minimal rule, giving nothing but the READ permit to the web visitor user and no other permits to no other users at all, you’ll end up with a very secure site, but with some annoyances, e.g. FTP uploading contents will fail probably with a “450 can’t access file” error.

In Windows, you can easily fix it by giving “full control” to the SYSTEM user at some entry point.

(4)

Some CMSs that support themes, like Worpress, might display a blank page after being moved or copied. One very simple solution is to install a new theme, activate it, then return to the original.

One workaround is to explicitly map some dummy extension, to the EXE that you want to use as the CGI application.
For example, map “.CSX” to the executable that is the output of your C# CGI solution.

The HTML that needs to invoke the CGI, must invoke the dummy (zero bytes) .CSX file, because invoking the .EXE would produce the IIS problem already mentioned.

In order to do the “.CSX” <—> “CGI.EXE” mapping, (1) create one server side directory (virtual or not) to hold the C# CGI solutions.

The picture below shows that, in some computer, the “\cgi-bin\cgi_cs” folder was chosen to hold the C# executables.

After (1), make sure that you (2) create an “IIS application” for the folder, having execute permissions for BOTH script and executables.

Once the application is created, it is possible to configure it. So, (3) click the configuration button.

(4) The relevant tab in “application configuration” is the “mappings” tab. Here, click the “Add” button. This operation is the way to build the aforementioned “.CSX” <—> “CGI.EXE” relation.

(5) In the “mapping” dialog, browse to the C# .EXE file that is intended to run as a CGI; then type “.CSX” as the extension; then you can uncheck the “check that file exists” option and, finally, press the OK button.

If the OK button is dimmed/grayed/not enabled, just click once on the executable textbox!

(6) After this, the “application configuration” dialog box should list the “.CSX” extension at the bottom.

In order to use the new mapping, restart (stop, then start) the IIS web server.

Having done these six steps, all that is left is to code the right invocation of the CGI. For example, if using forms and its action attribute, point the action to some empty .CSX file.

To build an empty CGI.CSX file, go to the “command prompt” and type “copy con cgi.csx”, followed by ENTER, followed by CTRL+Z (which is the end-of-file character).