Security Matters

Not all Web sites are meant to be open to the world via the Internet - some types, the most common examples being intranets and extranets, need to be secured from public access. You might also need to secure a subscription-only site, or perhaps just a small part of your main Web site intended for the press only.

If you read the documentation that comes with your Web server, it will no doubt say that securing your site is easy. Now go take a look at any support newsgroups or FAQs and you'll discover that theory and practice are at odds. The key to a secure Web site is authentication, which takes place when a file on the Web server (an HTML page, a script, a graphic or any other object) is protected so that the standard Web server process doesn't have access to it.

On most Unix-based Web servers this protection will take the form of a file called .htaccess, which stores, among other things, details of the users who are allowed to access the particular part of the site, plus an encrypted copy of their password (using simple Base64 encryption). On Windows NT and IIS, however, security is very much tied with that of the host operating system, which in theory should make life easy but actually causes most of the problems. Security on an IIS server is set using normal NT-style file protection ACLs via the Properties tab.

With either IIS or .htaccess-style security, when the server detects that authentication is needed for a page it sends an 'HTTP 401 Unauthorized' response to the requesting browser. Included within that response will be a list of the authentication methods supported by the server. The more common method is Basic authentication, which is the default method for .htaccess-style security. The problem with Basic authentication is that it's just that, basic. It requires you to type in a username and password, which are then encrypted by the browser and sent across the Internet to the Web server. However, the encryption used is so simple your granny could crack it. NTLM authentication is easier and more secure. First, before it pops up a security dialog it will try the username and password which you used when you started your Windows session and, second, it never sends passwords over the wire; instead, it sends a 'hash' value.

For the realm of personal home pages and small, static company sites, security (of a sort) really is this easy. But this is Real World Computing, so let's consider the world of interactive databases and application-driven sites, where you'll discover how NTLM authentication introduces one of the least understood IIS security problems. Take a typical scenario, where a browser (B) is accessing a Web server (W) over the Internet - this Web server being connected to a database server (D) running on the same network. If W reports to B that it needs authentication, it sends the 401 message with list of supported authentication types. This being an IIS server, it will probably be set up to support both Basic and NTLM methods, but it's left up to the browser to decide which method to use. MSIE supports both but will choose NTLM over Basic by default, while standard Netscape supports only Basic.

Under Basic authentication, a dialog box will pop up on B for the user to type in a username and password, which is then poorly encrypted and sent back to W for processing. To render part of the requested page, W has to drag some data out of D, so it simply passes on the user's username and password to D, which authenticates this and passes the data back to W, which then constructs the page and sends it back to B. Nice and easy.

Now, think about what happens under NTLM. B asks W for the page, but instead of sending the password it only sends the password hash. When W needs to pull the data from D, D will ask W to authenticate as the user, but this involves W sending D the username and password. Spot the problem? In this case W doesn't have the user's password, so it can't send it to D. It would appear that we can't use NTLM for anything other than simple static sites. Until NT 5 comes along with its Kerberos-based security, which removes this limitation, we're stuck with having to use the easily hackable Basic authentication scheme.

While we're waiting though, here's a little secret: there's a sneaky trick you can use to get around the problem. Since you know that NT works with password hashes, not true passwords, you can take advantage of the fact that, unlike with Unix, these hashes aren't machine-specific. The password 'wangleflacker' will hash to exactly the same value on W as it does on D. So if you create identical local accounts on both D and W, using exactly the same username and password, authentication can appear to take place. Of course, if you change the password on one server you'll have to remember to change it on the other as well.

We've already mentioned setting object security using ACLs and the standard NT Properties box, but there's another option. If your site is driven from scripts, you can use what we call Rizla security. In other words, roll your own. For example, if you want to force a page to authenticate using NTLM, you could use something like this at the top of your code:

<%
Response.Clear
Response.Buffer = True
Response.Status = "401 Unauthorized"
Response.AddHeader "WWW-Authenticate","NTLM"
Response.End
%>

This will pretend to the browser that the page requires authentication, even if the file protection says otherwise. If you wrap this up within some code that checks the server variable LOGON_USER you've got your own hand-rolled security system.