Article Options
Premium Sponsor
Premium Sponsor

 »  Home  »  Security  »  Security Smack Down
 »  Home  »  Web Development  »  Security Smack Down
Security Smack Down
by Tiberius OsBurn | Published  09/27/2002 | Security Web Development | Rating:
Tiberius OsBurn

Tiberius OsBurn is a Senior Developer/System Analyst for The Gallup Organization ( He recently completed a huge data warehousing project that archived data and documents from 1935 to the present - all coded in C#, SQL Server and ASP.NET.

Tiberius has extensive experience in VB, VB.NET, C#, SQL Server, ASP.NET and various other web technologies. Be sure to visit his site for his latest articles of interest to .NET developers.


View all articles by Tiberius OsBurn...
Security Smack Down

We did it.

We released a HUGE .NET project, all crafted with C#, SQL Server and ASP.NET.

Problems? You bet... but nothing at all like releasing in ASP 3.0 - in fact, given the circumstances, it was a big success. Microsoft has gone out of their way to provide some really great tools and documentation to make the launch of your .NET application as smooth as possible. Given the history of DLL HELL and trying to get dynamic libraries registered and running in MTS Services... well, you get the point.

I'll let you in on some of the security strategies we followed when deploying our ASP.NET application and also some of the problems that we encountered on the final days of release.

Security has always been a 'problem' with IIS, mostly because of the lackadaisical work habits of system administrators or developers wearing two 'hats'. Earlier this year, Microsoft rededicated the work of many programmers to security. This was a good move - but I'm not waiting until .NET Servers to do my work for me. I'll walk you through some of the easiest ways to lock down a machine and fix some of the snags that you might encounter when deploying an ASP.NET application.

<compiler language="c#;cs;csharp" 
	 type="Microsoft.CSharp.CSharpCodeProvider, System, 
	 compilerOptions="/nostdlib" />


First Rule: If you don't know what you're doing, don't do it.

I can't stress this enough - it takes a special kind of person to admit that they don't know what they're doing. Most of the time a good slap upside the head and then a few late nights with the IIS manual will cure 'IISitis'. Take the time to really understand what IIS is about - what permissions are, what services are on your machine. The days of 'out of the box' functionality are long gone. Guessing if something is going to work has been the death knell of many an administrator.

There are many, many resources out there to help those of you who suffer from IISitis - don't be afraid to ask for help.

Get Rid of It

See that sample folder? Do you know what it does?


Well wipe it out of your wwwroot - you don't need it. In fact, get rid of ANYTHING on your root you don't need. That includes files and folders that you're not currently using but could be exploited somehow, someway. It's not only good practice to release only files you'll actually be using; it also makes for good housekeeping on the server.

What's Script Mapping?

Say what? You've got to be kidding me... A script mapping is a 'shortcut' for IIS to interpret an extension on a requested file name, like .HTML or .XML. There are a lot of server mappings that you don't need. Avoid these like the plague.

Follow these instructions to remove some of the more commonly exploited server mappings - if you don't use the services....

  1. Open Internet Services Manager.
  2. Right-click the Web server, and choose Properties from the context menu.
  3. Master Properties
  4. Select WWW Service | Edit | HomeDirectory | Configuration
Web-based password reset.htr
Internet Database Connector.idc
Server-side Includes.stm, .shtm and .shtml
Internet Printing.printer
Index Server.htw, .ida and .idq

If you're using any of these, you've got problems. Just say 'NO'.

Windows Update Tool

Get it. Install it. Don't ignore it.

Although sometimes MS is sometimes a little late coming out of the chute when it comes to security patches, it's got a winner with the Windows Update Tool. It's a little icon that sits in the task bar and notifies you whenever there's a hot-fix or a patch available for your machine. If this had been around when the Code Red virus hit the world, it might have minimized the impact that nasty little bug had on the industry.

Service Pack


If you're one of those creeps that ignore the news when a service pack is released, don't come whining to me. I don't want to hear it. I'll bet you're still running Windows NT 4.0 without any updates - aren'tcha?

MS puts out a service pack for a reason. Don't play the 'macho' game of waiting till "it's stable" - that's a lame excuse for not doing your job.

Lock Down

First off, if you're not familiar with IIS or you're not a full time IIS administrator, don't mess with permissions. Period. If you're not a wiz with NT permissions, you could be opening up a hole wide enough to fit the entire "I Hate Bill" community - and that's not a good thing.

I suggest using the IIS Lockdown Wizard to close off any holes or security snafus that you might have lying-in-wait. It'll help you plug those holes that'll make the "little Dutch boy" blush.

Warning: This should take care of many of your permission problems, but don't fall into a false sense of security just because you ran a 'wizard'. There's more work to do after the lockdown wizard.

A few important features of the lockdown wizard include:

  1. Server Roles - These are basically templates of security settings. If you're running Outlook, you want security setting most suited for Outlook. If you're running a web site, you'll want to choose the server role that corresponds with IIS.
  2. Disable Services - With the lockdown wizard, you'll be able to remove or disable IIS services such as HTTP, FTP, SMTP and NNTP.

These features allow an IIS administrator to strip off unnecessary roles, permissions and services that ship 'out of the box' with IIS. Read up on this tool and use it.

Re-add Permissions

The IIS Lockdown tool works like a charm - but it doesn't take care of all of your problems - in fact, you might have to re-up security to a few folders, especially if you're using the System.Web.Mail namespace and the IIS Lockdown has stripped your box of SMTP permission.

In our case, we had to grant the ASPNET user permission to write mail to the SMTP 'outbox'. The ASPNET user needed WRITE access to the mailroot - you'll know when you bump up against a security setting that's too tight - you might not know when it's too loose.

Remember, it's always good practice to tighten down the hatches and then loosen them up as needed - rather than the other way around.

Don't Expose Yourself

Er... don't expose your errors! Make sure that your web.config custom error section is set to 'On' or 'RemoteOnly' when you've released. NEVER set this to 'Off' if you've released your application - you'll show the world your errors. To be on the safe side, keep your customErrors to RemoteOnly - this will show errors on your local (debugging) machine and never show the real cause of an error.

Your web.config error section should look like this:


Code Defensively

Ok, I'm going to sound paranoid but...

Don't trust anyone or anything.

Always check your Request.Params before you use the input.

Use RegEx to validate that your input is what you're expecting.

Make sure that you use stored procedures rather than hand-rolling SQL Statements.

Always plan that someone is going to try and jack your code - because someone will.

Down on the Web Farm

We're using a Round-Robin system for piping our end users to our clustered web-farm. Problem was, we forgot all about that damn view state. Don't know what I'm talking about? Well you soon will if you don't have your server keys synchronized. If you're using server side controls, running a web farm and plan on keeping view state from postback to postback... you'll be seeing this tasty little error:

The View State is invalid for this page and might be corrupted

If you're running a web farm this is pretty easy to fix - you'll need to make sure that the server keys on your farm all match. Why is this important? Because view state is encrypted via a server key - and there's no telling which machine an end-user may request a resource from or where they go after posting to a form. That's why it's important all keys on the web farm match up - so machine2 can decrypt the view state from machine1.

In the end, you'll modify your machine.config file and replace the existing <machineKey> section with the new key you'll generate. You'll need to do this on every machine you have on your web farm.

The end result will look something like this:

<machineKey validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2

Warning: Don't get lazy and copy one machine.config file around to all of your machines. You'll be very, very sorry.

C# Compiler Problems

One of the most vexing problems we encountered when deploying our C# application was a very funky error.

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.

Compiler Error Message: CS1595: 'System.Runtime.CompilerServices.CompilerGlobalScopeAttribute' is defined in multiple places; using definition from 'C:\winnt\\framework\v1.0.3705\mscorlib.dll'

The trick here was that since we've removed the Everyone and Users accounts for the security tight-down, the Csc.exe cannot snake out a valid path name - Basically, this occurs because the C# compiler does not have permission to access the folders in the path to the mscorlib.dll assembly. But don't make the mistake of slapping Everyone access on the\framework folder. We're concerned here with security, so what we need to do is modify our machine.config file and add a /nostdlib flag to our C# compiler definition.

<compiler language="c#;cs;csharp" 
type="Microsoft.CSharp.CSharpCodeProvider, System, 
compilerOptions="/nostdlib" />

Don't copy this verbatim into your machine.config or you could be in a world of hurt. Just add the compilerOptions="/nostdlib" directive after the warningLevel line - this tells your C# compiler not to import the mscorlib.dll assembly, which defines the entire System namespace.

Final Word

I hope this has been of some help to you when deploying your C# and ASP.NET application.

There are literally hundreds of resources out there that will help you lock down your application and site - but you'll have to do the 'hunt and peck' for most of the problems you'll encounter. Make sure that you keep and clear head and plan for problems ahead of time.

Security isn't just an administrator's business. It's everyone's business. Code defensively.

This should be your first stop when encountering problems with deploying applications on IIS.
This one is a no-brainer. Dev Teams all over the world encounter many of the same problems and errors that you're having - remember - you're not an island.;en-us;Q325864
Lockdown Wizard - This is an important tool in the arsenal of any ASP.NET administrator.;en-us;Q318274
C# compiler error - You may or may not get this. If you've locked down your machine and you're releasing with C#, I'm going to bet that you will. Follow the instructions for the first scenario and you'll be fine.
Windows Update Tool - This is a critical tool for all administrators, developers or users of the different flavors of Windows OS.
IIS 5.0 Checklist - Make sure you use it.;en-us;Q323744
View State - This is an error you'll get when you're deploying on a web farm.;en-us;Q312906
Creating Machine Keys - This article describes and provides all the code you need to make a machine key.
IIS 6.0 - A taste of the future of IIS...
Top Ten Security Tips in .NET

How would you rate the quality of this article?
1 2 3 4 5
Poor Excellent
Tell us why you rated this way (optional):

Article Rating
The average rating is: No-one else has rated this article yet.

Article rating:2.32142857142857 out of 5
 28 people have rated this page
Article Score18234
Sponsored Links