Securing ASP: A Deeper Cut

by AgentK  (kent@tegels.org)

In the article "Securing Websites With ASP" (17:1) by guinsu provided a primer on securing ASP-driven database-centric websites.  If you have not read that, it is worth doing now.

In this article, I am going to expand on some of the issues guinsu glossed over and discuss some alternatives.  Not that I am going to provide the end-all, do-all.  If you want that, read Richard Harrison's excellent book ASP/MTS/ADSI Web Security (1999, Prentice Hall).

SSL is Only Part of the Solution

One principal of modern information security is not to make your security undefeatable, but rather to make it so costly (in terms of time, computing, and other factors) as to deter all but the most determined.

Another principal is that the more you know about the parities in a transaction, the more trust you can have.  These principals manifest themselves as encryption and authentication.  Secure Socket Layer (SSL) is the current method of choice for encryption.  For good reason - at current levels breaking 128-bit based encryption would require incredible luck or barely imaginable computer power.

Defeating authentication is a different matter.

First, I recommend that you do everything you can to create "real" user accounts for secured site users.  By this I mean populate an ADS or NT Directory Service structure with accounts.  Then add these accounts to groups.

Finally, use NTFS ACLs to "lock down" the content and scripts to those groups.

Why not just store user accounts and password in, say, SQL tables?  Two reasons: Well-secured directory services tend to query and respond faster than comparable SQL structures.  And directory services tend to backup and recover quicker and better in the event of disaster than RDBMS services.

Keep in mind that IUsers will always use password (or something equally as inane) for their password.  The weaker the password, the less you should trust it.  What makes for good passwords?  As a starter, I prefer:

At least eight characters, six of which can be from the English alphabet excluding vowels.

At least two of which must be digits (0-9).

At least one must be one of !, $, ", or *.

No more than three of the characters in the password can be found in the User ID.

Logging users in can be an issue.  Unless you know that your clients are using Windows and IE exclusively (a pity, but it happens), you're probably going to have to rely on the so-called "basic authentication."  The level of password encryption here is, essentially, meaningless.  So, if you are going to have to do it, at least require that a secured channel (e.g., an HTTPS session) has been started first.  Then redirect to an ACL protected file set.

If you are going to have a secure site, SSL is certainly worth its weight in molybdenum.  But so is - if you cannot use some other authentication technique - requiring strong passwords.  Using directory services can be faster and more failure resilient.  The best affect is achieved by combining the three.

Understand Your Environment

What I mean by this is that you need to understand how to secure your physical platform, how IIS works, and what can go wrong.  Let's start at the hardware level.

A Good Foundation:

The most basic thing you "must" have for a security environment is a firewall.

In my opinion, Microsoft Proxy Server is not good enough in and of itself to fill this bill.  There's certainly nothing wrong with building a Solaris, Linux, or BSD firewall on an NT network, either.  In fact, it can offer some advantages.

Next, consider putting your Internet machines in a network that is otherwise detached from your internal network.  Yes, it would be nice if all the system were "completely integrated" in some respects.  Since you'll have to be willing to accept degraded security for your web platform, do you really want to risk everything on it?

One trick I've used is to use private networks with networks.  For example, suppose you have three IIS servers with an exposed, registered IP address and you need an SQL server.

There's very little reason to use an exposed, registered IP address for that.  If you can use IPX/SPX, you could just add an extra NIC to each web server and to the SQL server, bind IPX/SPX to those.  Thus web servers can talk free to the SQL server, but you eliminated some risks by not exposing the SQL server to IP-based attacks.  If IPX/SPX is not an option, use private and not normally routed (10.x.x.x, 172.16.x.x, and 192.168.x.x) IP addresses to connect machines.

By the way, never put both IIS and SQL on the box if at all possible.  You're just begging for both performance and security issues by doing this.  NICs and hubs are cheap.  Lost orders and leaked client information may not be.

The ASP Object Model

ASP is really nothing more than an application that runs inside the ASP process.

In some respects, ASP is nothing more than a script interpreter.  What is different about ASP is that it also retains state by the use of application and session objects on the server and response and request objects formed from the HTTP transactions.

I could go on and on about this, but prefer not to.  Get a copy of ASP 3.0 Programmer's Reference by (2000, Wrox Press) for the nitty-gritty.

Guinsu discussed the session object at length.  Most of what he said was accurate.  To overcome some of these issues, I recommend that all you store in session is one or two things: some unique key to represent the user (or user-session) and a reference to an MTS object that contains your data.  This gets a bit complicated of course, but really helps both performance and security.

One thing that I would point out is that cookies are becoming more universally accepted but if your clients refuse them, you can use server-side persistence instead.  Basically, this works as long as you can safely assume that your client will have a fixed IP address (or certificate serial number) for the duration of their visit to your site.  You could then devise some data store using this as the key.

Something I felt did not get well explained is that ASP uses COM (and COM+) to pass scripts off to an interpreter.  Thus, as long as the programming language you choose to use supports COM, you can use it within ASP.  I prefer PerlScript, from ActiveState's ActivePerl.  For what it's worth, Perl is not PERL.

What Can Go Wrong?

Like any system, power outages, theft, fire, and other common perils must be considered.  But some Microsoft procedures and products can yield unannounced problems.

A key one to consider is FrontPage and the FrontPage Server Extensions (FPSE).  There are others, of course.

Ask any level headed SysAdmin about FPSEs and if you don't get a "bitter beer face," you'd better disable their account quickly (or at least make them recite "Security Considerations" from the "FPSE Resource Kit" three times, out loud, and in their underwear before the CEO and CIO).

Remember that FrontPage was originally designed to make Web publishing easy.  It overachieved.  Part of the simplicity of FrontPage is that it managed the marshaling of files to and from Web servers transparently.  When installed on default NTFS or FAT partitions, anybody with FrontPage can access and edit files too easily.

They can even upload harmful scripts and executable files.  This is obviously not a good thing.  Even more insidious, since FPSE are programs, they are susceptible to class attacks like buffer overflows.  I do not know that "Netscape engineers are weenies" any more than Microsoft developers are a little too willing to compromise good security for ease of use.

Yet, you can actually tame these parasites - it just takes a little work.

When installing on Windows systems, make sure that you put your \inetpub\ root only on an NTFS partition.  Make absolutely sure to completely remove the "everyone" group from the ACLs for the partition or path before you install IIS (or as soon as you possibly can thereafter).

Do not, however, deny "everybody," as nobody, not even the Administrators, will be able to access those directories.  For good measure, I also turn on most of the auditing features for this path - just to see what people are doing.

Installing the most current version of the Microsoft Data Access Components (MDAC) is also a prudent thing to do before installing IIS on Windows NT 4.0

Next, make sure you have the most current version of the extensions installed for your platform.  The ones that ship "Option Pak 4" and on the FrontPage 98 media aren't.  Install these immediately after you get the IIS service installed and well before you connect the machine to an Internet pipe.

Then run the FPSE administration program and run the "check and fix procedure."  This will give you the option of "tightening security" which you should do as soon as possible.  And, as a matter of practice, install every service pack and hot fix appropriate thereafter.

Something that's getting a lot of play as I write this are "denial-of-service attacks."  DoS attacks are not hacking and you're not "l33t" because you can do them as far as I'm concerned.  On the other hand, if you aren't designing your web apps considering that somebody will pound it just to see how much abuse it can take, you are not doing yourself any favors either.

If you create a bunch of objects during "Session_OnStart", even the "Human Ping of Death" could knock out easily.

Rule of Thumb #1:  Create session objects sparingly, if at all.

Rule of Thumb #2:  Expire objects as quickly and explicitly as possible.  A sluggish server is almost always better than a dead one.

A small but dark cloud for you Windows 2000 folks: Watch out for WebDAV.

WebDAV (the Web Distributed and Versioning Protocol) extends HTTP's command set to allow FPSE like functions (and therefore, weaknesses) without FPSE muddling the picture.  With WebDAV and enough access rights, folks can open, edit, and save virtually any file they have access to remotely.  Again, taking great pains to edit your ACLs can impede the abuse of WebDAV.

There are a couple of other components to keep an eye on too.

One of these is the FileSystem Object and its ability to read and write files on the server (see Chuck Newman's "Sharing Too Much" at www.webtechniques.com/archives/2000/04/newman.

Also, be very careful with any object-code library that lets users put files to server (SAFileUp and AspUpload).  You're just asking for a Trojan horse if you make those too easy to find and use.

Sleeping Well at Night

So, with all of these threats, gotchas, and gremlins in the ASP environment, can you sleep well at night, assuming that your web servers are safe?

Taking the steps outlined herein can help, but the best you can hope for is that you've made it tough enough to break your site that the slHackers will go elsewhere for fun.

The keys to a good night's slumber are: using strong encryption and authentication; understanding and hardening your environment and keeping abreast of, and reacting quickly to, what can go wrong.