Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM

( 3 )


Developers of Web-based applications get expert guidance for taking advantage of the sophisticated security features in Windows 2000 — all in one comprehensive volume. This definitive guide provides a solid foundation in security theory and concepts, explains the key software design considerations for various categories and levels of security, and discusses ways to apply the appropriate security to mitigate risk. It also covers a range of security technologies, including NTLM authentication, Kerberos ...

See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (11) from $1.99   
  • New (4) from $39.99   
  • Used (7) from $1.99   
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2008

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.


Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
Brand New Item.

Ships from: Chatham, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Seller since 2008

Feedback rating:


Condition: New

Ships from: Chicago, IL

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Sort by
Sending request ...


Developers of Web-based applications get expert guidance for taking advantage of the sophisticated security features in Windows 2000 — all in one comprehensive volume. This definitive guide provides a solid foundation in security theory and concepts, explains the key software design considerations for various categories and levels of security, and discusses ways to apply the appropriate security to mitigate risk. It also covers a range of security technologies, including NTLM authentication, Kerberos authentication, SSL/TLS, CryptoAPI, ACLs, Active Directory services, certificates, and COM+ security.

Read More Show Less

Product Details

  • ISBN-13: 9780735609952
  • Publisher: Microsoft Press
  • Publication date: 8/26/2000
  • Series: DV-MPS Designing Series
  • Edition description: 2000 ed.
  • Pages: 450
  • Product dimensions: 7.40 (w) x 9.20 (h) x 1.39 (d)

Meet the Author

Michael Howard, currently a program manager on the Windows 2000 security team, has been at Microsoft for 8 years. Prior to working on Windows 2000 he was the security program manager for Internet Information Server 4.0 and 5.0. Michael has spoken about security-related issues at many events such as Microsoft TechEd, Microsoft Professional Developer's Conferences and numerous industry gatherings. He hails from New Zealand, where he worked with banking and government clients helping them design, develop and deploy Windows NT-based security solutions. Currently, Michael lives 10 miles from the Microsoft Redmond campus in sunny Bellevue with his wife, Cheryl and two Yorkshire Terriers; Squirt and Major.
Read More Show Less

Read an Excerpt

Chapter 5 Internet Information Services Security Overview

InternetInformation Services (IIS) 5 is a mature, high-performance Microsoft Windows 2000-based Web server, which builds on the success of IIS 4, the most popular Web server for Microsoft Windows NT 4. In this chapter, we'll examine some of the security features of IIS 5 as well as some of the server's new functionality.

Because IIS is a Windows 2000 system service and relies heavily on the security functionality in Windows 2000, it's assumed in this chapter that you have read Chapter 3, "Windows 2000 Security Overview," or have a good working knowledge of Windows 2000 security.

We'll cover the following topics in this chapter:

  • Internet authentication
  • Web authentication protocol details
  • Anonymous access
  • Basic authentication
  • Digest authentication
  • Integrated Windows authentication and the Negotiate protocol
  • X.509 client certificate authentication
  • Configuring SSL/TLS
  • IIS authorization-the marriage of Windows 2000 security and the Web
  • IIS process identities

A New Feature of IIS 5-WebDAV  Defined in RFC 2518 (, Web-based Distributed Authoring and Versioning (WebDAV) is a set of extensions to the HTTP 1.1 protocol that allows users to collaboratively edit and manage documents on Web servers. IIS 5, Microsoft Internet Explorer 5, and Microsoft Office 2000 support WebDAV.

You can find more information about WebDAV at the WebDAV Resources Web site ( and at the Microsoft Developer Network (MSDN) Web site at

Internet Authentication

There are three types of Web access in a Web application, be it on the World Wide Web or on an intranet:
  • Anonymous access
  • Identified access
  • Authenticated access

In the anonymous access scenario, you don't care who the user is-users have access to all the resources you want them to have access to and no more. A good example of this is simple Web presence; most Web sites use anonymous access for their home page and their marketing or sales material. For example, the vast majority of uses anonymous access, including its sales, marketing, and developer-related materials.

Identified access is for Web areas where you are providing personalized services-you are not giving users access to private data known only to the company and the user. For example, you have the option to customize the home page of The Microsoft Network,, so that you can see your favorite stock quotes, news sources, leisure categories, and so on. This Web information is not confidential; it is customized.

In the authenticated access scenario, you need to know who the user is and the user has to have access to data that might be private, sensitive, or personal.

Notice that as you progress from anonymous to authenticated access there's a greater need to trust the user's credentials, as shown in Figure 5-1. For anonymous access, there's far less of a need to know who the user is; in fact, some might argue that you needn't care at all. For identified access, you need to know who the user is but only to the extent needed to provide a service or personalized but public content associated with that identity. With authenticated access, access is denied if you cannot confirm the credentials of the calling user.

Figure 5-1. Valuable information requires stronger credentials.

Each of these scenarios depends on the degree to which you trust the credentials supplied by the user. Anonymous access requires no credentials, identified access uses weak credentials, and authenticated access requires strong credentials. The strength of the credentials required is related to the value or sensitivity of the data you are providing. This is not to say that sales and marketing information available to all users is not valuable, but it is not as valuable as projected sales and marketing information internal to the organization.

In the example shown in Figure 5-2, the public area of the fictitious Exploration Air Web site requires no authentication (anonymous access), and the internal part of the site requires either HTTP 1.1 Digest authentication or Integrated Windows authentication, both of which are covered later in this chapter. The directories used to serve the content should be controlled by access control lists (ACLs) according to who the users are. Notice the use of the Deny access control entry (ACE) for the anonymous user account on the internal directory in the figure. If the administrator accidentally sets anonymous access as a valid authentication scheme, the anonymous account will still be denied access to the site content because of this ACL setting.

Figure 5-2. Public data requires weak or no credentials; private or confidential data requires stronger credentials using authentication techniques.

Authentication Protocols Supported by IIS 5

Before we look in depth at the authentication protocols supported by IIS 5, an overview of how Web authentication works is in order.

Web authentication protocol details  Web authentication requires multiple interactions between the Web browser and the Web server. The general steps, as shown in Figure 5-3, are as follows:

  1. The browser requests data from the server by using an HTTP GET verb.
  2. If the Web server requires the client to authenticate himself, it sends an HTTP 401 error back to the browser, along with a list of the authentication schemes it supports and data, often called a challenge, with which the client can resubmit the request. The challenges are sent as one or more WWW-Authenticate headers in the server's response.
  3. The browser chooses an authentication scheme it supports and reconstructs the request to include a response to the challenge. The response is data based on the user's credentials and the challenge data sent by the server. The response is sent back as part of an Authorization header. Note that Internet Explorer will always pick the first authentication scheme if given the option of choosing from multiple authentication schemes. For example, if Basic authentication is listed before Digest authentication, Internet Explorer will pick Basic.
  4. The browser reissues the request including the response data.
  5. The server authenticates the newly submitted data and, assuming all is well, sends the response, and the requested resource, back to the user, including an HTTP 200 status code - no error message.

Figure 5-3. Overview of Web authentication protocols data flow.

When the server sends an HTTP 401 error to the client, it sends a list of supported authentication protocols. Therefore, if your Web server supports authentication protocols A and B, you must be willing to accept credentials from the weakest protocol because the browser might understand (or choose) only the weaker protocol. If you're not willing to accept weak credentials, you should not select that protocol for your Web site.

As shipped, the Web server in IIS 5 supports the following authentication .protocols:

  • Anonymous access
  • Basic
  • Digest
  • Integrated Windows
  • X.509 client certificates

Each of these is explained in detail in the following sections, so let's get started with the weakest of all the authentication schemes, anonymous access.

Anonymous access  Technically, anonymous access is not an authentication scheme because the calling user is never asked to present credentials such as a password. However, Windows 2000 requires that all users authenticate themselves before they access any resource. To this end, IIS provides a default user account called IUSR_machinename as the Anonymous User account for anonymous access. All anonymous access is performed in the context of this account.

The account is defined at setup time with a very strong password-comprising uppercase and lowercase letters, numbers, and punctuation-and can be changed by the administrator later, but you are not obliged to use this and only this account for anonymous access. In fact, you can set different user accounts to be used in different parts of your Web space, such as at a Web server, virtual directory, directory, and file levels.

You can change the account in the IIS administrative tool like so:

  1. Right-click the My Computer icon on your desktop.
  2. Choose Manage from the context menu.
  3. Expand the Services And Applications node.
  4. Click Internet Information Services.
  5. Right-click the Web server, virtual directory, directory, or file in question.
  6. Choose Properties from the context menu.
  7. Click the Directory Security tab.
  8. Click Edit in the Anonymous Access And Authentication Control box.
  9. Make sure Anonymous Access is checked.
  10. Click Edit.
  11. Enter the account name and the account password. If the password box is grayed out, you need to clear the Allow IIS To Control Password check box first.
  12. Click OK three times.

You can also set the anonymous account programmatically by using Active Directory Services Interface (ADSI). Refer to Chapter 13, "Security Administration with ADSI, WMI, and COM+," for an example.

It is imperative that the Anonymous User account be an account with few privileges, minimal group membership, and minimal access to resources.

Failure to configure the account this way will compromise the security of your Web site because all anonymous access will operate in the context of the anonymous account. You have been warned!

Why change the Anonymous User account?  It's useful to change the Anonymous User account if you host multiple Web sites. You can set up one Anonymous User account per Web site and set ACLs on the resources used by that Web site. For example, say you host and You could then set the account for to be AnonA and the account for to be AnonB. The scenario would look like that in Figure 5-4.

Figure 5-4. Using different Anonymous User accounts for different Web sites.  Privileges required when using the Anonymous User account  There has been much confusion about the Anonymous User account and anonymous access in IIS relating to which privileges are required for the account. The question is, "Does the Anonymous User account need network logon or interactive logon privileges?"

The answer is, it depends!

If you have the Allow IIS To Control Password option checked in the Anonymous User Account dialog box, the account must have the Access This Computer From The Network privilege; otherwise, the Log On Locally privilege is required. IIS will log the account on using different techniques, depending on the Allow IIS To Control Password setting, which is our next topic.

The Allow IIS To Control Password setting   If the Allow IIS To Control Password setting is checked, IIS calls a subauthenticator to validate the password. Subauthenticators are implemented as dynamic-link libraries (DLLs). A subauthentication DLL allows the authentication information stored in the Windows 2000 user account database (the Security Accounts Manager [SAM] or the Directory) to be augmented with other account validation capabilities.

For example, a server might supply a subauthentication DLL that validates a user's password via a different algorithm or specifies special workstation restrictions. All of this can be accomplished using subauthentication DLLs without sacrificing the use of the Windows 2000 user account database and its administration tools.

IIS 5 supplies a subauthentication DLL called IISSUBA.DLL to verify that the password is correct and then informs Windows 2000 that the password is valid so that the user can log on. Note that this functionality is available in Internet Information Server 4 also.

Accounts authenticated using a subauthentication DLL are always network logons and thus must have the Access This Computer From The Network privilege.

Only administrators can add subauthenticators to the operating system.

For more information about subauthentication DLLs, refer to the MSDN CDs or to

If Allow IIS To Control Password is not checked, IIS will log the account on using the Windows API LogonUser and pass in the name of the Anonymous User account as well as the password, both of which are stored in the IIS configuration store, the metabase. Hence, if the control password setting is not set, the anonymous account must have the Log On Locally privilege.

Basic authentication  Basic authentication is a simple authentication protocol defined as part of the HTTP 1.0 protocol defined in RFC 2617 (available at Although virtually all Web servers and Web browsers support this protocol, it is extremely insecure because the password is in cleartext (also called plaintext), meaning it's passed over the network "in the clear." (Actually, it's not in the clear; it's base64-encoded, which is so trivial to decode that it might as well be cleartext!). Basic authentication works well through proxy servers and firewalls.

Basic authentication, as implemented in IIS 5, requires Windows 2000 accounts, either in the SAM or in Active Directory. This allows the Web site to use ACLs to determine access to resources. When a user connects to a Web site using Basic authentication, IIS gets the username and password from the HTTP Authorization header, calls the LogonUser API, and then impersonates the user.

By default, users accessing your Basic authentication Web server need the right to log on locally, although this can be changed in the IIS metabase by using ADSI. Refer to Chapter 13 for this method.

So, why change the logon type? The LogonUser API allows you to determine how the account is logged on. For example, the account can be logged on using log on locally, network, or batch privileges. Interactive logon is the default because it's the most flexible setting for most environments; it's not necessarily the most secure. Giving users this privilege allows them to log on to the Web server if they have physical access to the server.

The flexibility of a local logon is a legacy of Windows NT 4 and IIS 4. If an account is authenticated using NTLM or is logged on with network privileges, the account cannot access secured resources on another remote computer. While the issue of client delegation is resolved in Windows 2000 by using Kerberos, the only way to work around this in Windows NT with IIS 4 and Windows 2000 with IIS 5 in a non-Active Directory environment is to log the account on using log on locally privileges.

With log on locally privileges, information about the client, such as group membership and privileges, is stored so that the account can perform an offline logon if the server performing the logon cannot access a domain controller. The downside to storing this information is its effect on speed-it takes a certain amount of time to load and store the data.

Nevertheless, you can get the best of both worlds-speed and the ability to "hop" onto a remote server securely-by using the batch logon privilege. However, few user accounts have this privilege, so you must grant the privilege to the users in question.

The Network Logon With Cleartext password setting  Just to make things a little more interesting, there's another option! Once you give a user the network privilege-again, the Access This Computer From The Network privilege-you can allow the user to hop off the IIS server and onto a remote server by using a flag in the call to LogonUser that is new to Windows 2000: the Network Logon With Cleartext password setting. This is a new implementation in Windows 2000 of the network logon, a way of using the network privilege when calling LogonUser. This capability can be set only by using ADSI, as we'll describe in Chapter 13...

Read More Show Less

Table of Contents

Ch. 1 Security 101 3
Why Build Secure Applications? 3
Security Defined 4
Why is Security Difficult? 4
The Golden Rules (and Some Others) 7
Threats, Safeguards, Vulnerabilities, and Attacks 12
Ch. 2 A Process for Building Secure Web Applications 15
A Security Design Process 16
Application Design 26
An Example 28
Ch. 3 Windows 2000 Security Overview 43
The Impact of Active Directory 44
Authenticated Logon 45
Authentication 46
Privileges 47
User Accounts and Groups 48
Domains and Workgroups 48
DOMAIN/Account Names and User Principal Names 49
Managing Accounts 51
Security Identifiers (SIDs) 53
Tokens 54
Access Control Lists 57
Impersonation 68
Delegation 69
Miscellaneous Windows 2000 Security Features 73
Ch. 4 Internet Explorer Security Overview 85
Privacy 86
Code Safety and Malicious Content 87
Security Zones 89
SSL/TLS and Certificates 93
Cookie Security 95
Ch. 5 Internet Information Services Security Overview 99
Internet Authentication 100
Configuring SSL/TLS 134
IIS Authorization - the Marriage of Windows 2000 Security and the Web 149
IIS Process Identities 154
Ch. 6 SQL Server Security Overview 163
Security Modes 163
Logins, Users, and Permissions 166
Network Security Options 169
SQL Server Logins 170
SQL Server Database Users 175
SQL Server Database Roles 178
SQL Server Permissions 181
Ch. 7 COM+Security Overview 191
Architecture 192
COM+ Authentication 194
COM+ Authorization 199
Debugging Tips 210
Using DCOM over the Internet 212
Ch. 8 Practical Authentication and Authorization 217
Where to Perform Authentication and Authorization 218
Application vs. Operating System Identity Flow 222
Relative IIS Authentication Performance 222
Example Authentication and Authorization Scenarios 223
A Warning About Custom Authentication and Passwords 244
Ch. 9 Practical Privacy, Integrity, Auditing, and Nonrepudiation 247
Privacy and Integrity Overview 248
Where Privacy and Integrity Issues Occur 250
Mitigating Privacy and Integrity Threats 255
Auditing 276
An Introduction to Nonrepudiation 279
Ch. 10 Building a Secure Solution 287
Putting Together a Secure Solution 289
Speed vs. Security Trade-Offs 303
Configuration Checklists 305
Ch. 11 Troubleshooting Secure Solutions 309
Tools and Logs Available to You 309
The Art of Reading a Windows 2000 Logon Event 315
The Art of Reading an IIS Log Entry 321
Problems and Solutions 322
Ch. 12 Securing Against Attack 337
Why People Attack Web Servers 338
How People Attack Web Servers 339
Some Common Attacks 353
How to Detect Whether You're Under Attack 362
User Input Attacks 375
What to Do If You're Under Attack 383
Staying Up-to-Date on Security Issues 384
A Final Thought 385
Ch. 13 Security Administration with ADSI, WMI, and COM+ 389
What is WMI? 390
What is ADSI? 390
Example Management and Security Configuration Code 391
Ch. 14 An Introduction to Kerberos Authentication in Windows 2000 407
What is Kerberos Authentication? 408
How Kerberos Authentication Works 410
Helpful Tools 413
Kerberos Ticket Flow 414
Ch. 15 An Introduction to Cryptography and Certificates in Windows 2000 423
The Fundamentals of Cryptography 424
The Basics of Certificates 434
Cryptography and Certificates in Windows 2000 450
Bibliography 471
Index 477
App. A Windows 2000 Well-Known SIDs
App. B Strong Passwords
App. C Windows 2000 Default Ports
App. D Internet Information Services Authentication Summary
App. E Security-Related IIS Server Variables
App. F Secure Web Server Checklist
Read More Show Less

Customer Reviews

Average Rating 5
( 3 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 3 Customer Reviews
  • Anonymous

    Posted October 19, 2000


    I've read many books about computer and network security, and this blows away all of them. It's easy to read, extremely pragmatic and, as far as I know, it is the ONLY BOOK that discusses how to design, build and troubleshoot end-to-end security. The degree to which Michael discusses 'real-life' security issues is incredible, there is so much information in this book, and I thought I knew how to build secure solutions. You gotta buy this book, it'll save you time and consulting fees

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted August 22, 2000

    Excellent Book

    I have found this book an easy read with precise information.... This is a must read for anyone who works with windows and is security conscious.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted August 7, 2000

    Should be part of every serious developer's library

    This title covers in a very readable form many areas of Windows 2000 security. There are also a number of useful tools on the CD. For example, a C/C++ common buffer-overrun problem API analyzer. This along with Keith Brown's Programming Windows 2000 Security are 'must buys.'

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 3 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)