Mitigating Privacy and Integrity Threats

[Previous] [Next]

Having described some points of vulnerability in a Web application, now we'll take a look at technologies that can be used to mitigate the threats. As you might have noticed, two major categories of issues exist:

  • Threats to the privacy and integrity of data that travels to and from the client (that is, the end-to-end scenario)
  • Threats to the privacy and integrity of persistent data, or protection of data when held in persistent storage, such as on disk or in databases

The following sections discuss countermeasures to these threats.

End-to-End Security Protocols

In the end-to-end scenario, data must be secured as it flows from the client to the server and back. Using an end-to-end security protocol can mitigate privacy risks because the data is encrypted while it passes through intermediate servers and routers. Integrity risks are mitigated by using cryptographic hash functions that detect changes in the data. Usually, data traveling between the client and server is secured because a secure channel is negotiated at communication start and data then flows across the secured channel. Sometimes, the encryption key used to encrypt the channel is renegotiated at regular intervals to provide extra security.

End-to-end protocols are common on the Internet today. Example protocols include the following: SSL/TLS, IP Security (IPSec), PPTP, and L2TP. PPTP and L2TP are used for virtual private network (VPN) scenarios and are beyond the scope of this book. IPSec is a secure implementation of the IP protocol that supports authentication, privacy, and integrity. However, the most common protocol by far is SSL/TLS, which is our next subject.

The Secure Sockets Layer/Transport Layer Security protocol

SSL—also referred to by its name ratified by the Internet Engineering Task Force (IETF), TLS—is a security protocol providing authentication and protection against eavesdropping (privacy) and data tampering (integrity). Authentication is provided by X.509 certificates and proof of possession of the associated private key. Privacy is provided through data encryption. Integrity is provided by hash functions and Message Authentication Codes (MACs).

The main threats that SSL/TLS helps alleviate are

  • Identity spoofing (by providing strong authentication)
  • Information disclosure (by encrypting the communication channel)
  • Data tampering (by providing message integrity codes)

How SSL/TLS works

A number of steps occur when an SSL/TLS session is established between the client and server. Figure 9-3 shows the main high-level negotiation stages. The figure's purpose is not to show every byte of each phase of the protocol; rather, it's to help you gain an understanding of why the stages occur. The figure assumes that the Web server is not configured to request a client authentication certificate.

For SSL/TLS to work, the Web server requires a certificate and private key. A core premise of SSL/TLS is that a certificate owner must prove that it owns the private key associated with the certificate. In other words, the authentication credential is the private key used in conjunction with the certificate. Having a certificate and private key allows the client to verify that the server is the server it claims to be. Once this trust is established, the two parties can agree on a key to use for encrypting data. This is an incredibly important step because you need to be sure of the identity of the server before you can have a private communication!

click to view at full size.

Figure 9-3. High-level view of the SSL/TLS handshake process.

The difference between SSL and TLS

SSL was invented by Netscape and became a de facto standard because the browsers and Web servers made by both Microsoft and Netscape included the technology, which lowered the entry barrier for Web sites and users alike. As e-commerce became widespread in the mid-to-late 1990s, the need for a secure means of transferring user and credit card information across the Web became paramount. E-commerce acted as the main catalyst of SSL's popularity. Two main versions of SSL exist: version 2 and version 3. SSL version 3 is much preferred over SSL version 2 because it fixes many more security weaknesses. The technical differences between the versions are beyond the scope of this book.

In 1996, the IETF decided to standardize the SSL protocol and in doing so renamed it Transport Layer Security. The current version is TLS version 1. Internally, the version number is 3.1 because TLS is a minor enhancement of the SSL protocol. Effectively, TLS is SSL 3.1. TLS is now an IETF standard, RFC 2246.

SSL/TLS port numbers

The standard port for HTTP traffic over SSL/TLS, otherwise known as HTTPS, is 443. However, SSL/TLS is not restricted to protecting HTTP data; SSL/TLS can be used to protect other Internet protocols. Some standard Internet protocols and their port numbers when using SSL/TLS include those shown in Table 9-1.

Table 9-1. Common SSL/TLS-enabled protocols.

ProtocolPort Description
HTTPS 443 HTTP over SSL/TLS
SMTPS465SMTP (e-mail) over SSL/TLS
NNTPS 563NNTP (news) over SSL/TLS
LDAPS 636LDAP (directory access) over SSL/TLS
POP3S995POP (e-mail) over SSL/TLS
IRCS 994IRC (chat) over SSL/TLS
IMAPS 993IMAP (e-mail) over SSL/TLS
FTPS990FTP (file transfer) over SSL/TLS

Web browsers know to use port 443 rather than port 80 when you type https://www.exair.com rather than http://www.exair.com and will attempt to set up an SSL/TLS session with the server; the connection will fail if the server is not configured to use SSL/TLS.

NOTE
It's worthwhile to add a small lock icon to your secured Web pages, just in case the lock symbol in the browser is not visible. You might also want to include a comment explaining how your users can confirm the security of the Web page in their browser. If they're using Microsoft Internet Explorer, they can right-click the page and select Properties from the context menu. If they're using Netscape Navigator, they can click the lock icon in the status bar.

SSL/TLS performance

Owing to the cryptography required by SSL/TLS, the protocol can significantly degrade performance on your Web application. Table 9-2 gives you an idea of the performance characteristics of the various protocols. The test machine was a one-processor Pentium III Xeon running at 450 MHz. The requests/second figure is for new connections; once the connection is established, the throughput increases dramatically.

It might surprise you to learn that the implementation of SSL/TLS in Windows 2000 is slightly faster if the key size is 128-bit, rather than 40-bit or 56-bit, because of the way SSL/TLS implements keys. All keys are 128-bit; however, in situations where the key must be less that 128-bit, say 56-bit, the key is split into a 56-bit key and a 72-bit salt. Keeping track of this takes time; it's quicker to use a 128-bit key with no salt. The number of connections per second drops off dramatically if you increase the exchange key size from 512-bit to 1024-bit. Expect to see about a five times decrease. RSA is extremely slow in software, and as the key size grows the performance of RSA degrades rapidly.

Table 9-2. Relative PCT, SSL2, SSL3, and TLS performance.

ProtocolCipher Hash Key ExchangeRequests/ Second
PCT 40-bit RC4MD5 512-bit RSA 108
SSL240-bit RC4 MD5512-bit RSA 77
SSL356-bit RC4SHA-1512-bit RSA83
TLS 56-bit RC4SHA-1 512-bit RSA90

With all this in mind, you should use SSL/TLS only where it is needed. The next section introduces some ways to reduce the impact of using SSL/TLS on your Web site.

SSL/TLS best practices

The problem with SSL/TLS is the performance overhead required when establishing new connections. A new connection consumes a great deal of CPU time because of the complex cryptographic public key operations required. Once the connection is established, however, encryption overhead is much smaller. To increase the speed of your Web site running SSL/TLS, follow these simple rules:

  1. Keep the SSL/TLS portion of your Web site to a minimum.
  2. As already noted, you probably don't want to require SSL/TLS on all parts of your Web site, because most pages hold nonprivate information, such as marketing, sales, and technical documents that anyone can view. Use SSL/TLS only if you're sending confidential or sensitive data to your users—all other parts of your Web site should not require a secured connection. Details about enabling SSL/TLS on certain parts of the Web site are discussed in Chapter 5, "Internet Information Services Security Overview."

  3. Keep the SSL/TLS pages simple.
  4. All content on pages requiring SSL/TLS, no matter the pages' size, must be encrypted, including images. Therefore, you should keep the number of images on secured pages to a minimum and keep the pages themselves simple. If you must use images, try to keep them small by using high JPEG compression and keeping the color depth low—don't use a 16 million-color palette for an image that requires only 256 colors.

    Some Web developers make the mistake of putting images in a directory that does not require SSL/TLS and referencing them from the pages requiring SSL/TLS. This sometimes causes browser warnings because the browser sees a combination of secure and insecure data. It's recommended that you don't do this—it's likely to confuse your users.

  5. Reuse cached SSL/TLS connections.
  6. Establishing a new SSL/TLS connection takes approximately five times as long as reconnecting using a cached SSL/TLS connection. The default time-out for such a connection is five minutes, raised from two minutes in Windows NT 4. You can extend the cache lifetime by setting the ServerCacheTime Registry subkey, as shown next. The value is measured in milliseconds—for example, 300,000 is five minutes.

     HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \SecurityProviders \SCHANNEL ServerCacheTimeout: REG_DWORD : 300000 

    Consider the setting you choose carefully: if you make the time-out too long, the system might start consuming memory while it caches stale SSL/TLS connections.

  7. Use cryptographic hardware accelerators.
  8. Compared to many other Web servers, Internet Information Services (IIS) is extremely fast at handling new SSL/TLS connections. For example, on a 500-MHz Pentium III-class computer, IIS 5 can handle over 60 new SSL/TLS connections per second. Although this might not seem high, it compares extremely well with another Web server that performs approximately 10 SSL/TLS connections per second on similar hardware. However, IIS is capable of exceeding 1000 anonymous, non-SSL/TLS connections per second. To increase Web server throughput, you can use special hardware accelerators from companies such as nCipher (www.ncipher.com) or Compaq (www.atalla.com). These devices offload the complex and slow public key operations and perform the work in custom-made hardware. Depending on the hardware used, you might not see an increase in the number of SSL/TLS connections per second, but you'll always see a drop in CPU time when establishing new connections.

NOTE
If you're a cryptographic hardware vendor, Microsoft has provided a simple way to offload some of the most CPU-intensive work, modular exponentiation, to your hardware: the OffloadModExpo function. You can provide a dynamic-link library (DLL) that exports this function and passes the work to your hardware. For more information, refer to the OffloadModExpo function in Microsoft Developer Network (MSDN).

SSL/TLS and client access licenses

In IIS 5, each concurrent, unique authenticated connection and each unique SSL/TLS connection consumes a client access license (CAL). By default, the number of CALs is the same as the number of Windows server CALs. For example, if your Windows 2000 server has 250 server CALs, your Web site can accept any number of anonymous connections up to 250 SSL/TLS connections and 250 authenticated connections.

NOTE
Actually, it's a little more complex than this. One CAL enables four concurrent connections from one machine to accommodate framesets.

An unlimited Internet license is also available, which allows any number of simultaneous SSL/TLS and authentication connections for a Web server on the Internet. Refer to Knowledge Base article Q253239 at http://support.microsoft.com/support/kb/articles/Q253/2/39.asp for further details about IIS 5 and CALs, and refer to "Windows 2000 Client Access Licensing Overview" at http://www.microsoft.com/windows2000/guide/server/pricing/model.asp for more information regarding client access licenses.

A little-known fact about SSL/TLS in Windows

The following information technically doesn't relate to privacy or integrity; it concerns using SSL/TLS for authentication. SSL/TLS can support wildcards in the common name of the server certificate. For example, when you connect to www.explorationair.com, the common name in the certificate will read www.explorationair.com also. It's possible to use a wildcard certificate that applies to multiple Web sites maintained, in this example, by Exploration Air. For example, development.explorationair.com is in the explorationair.com domain. The common name in the certificate could read *.explorationair.com, and the certificate might be used at www.explorationair.com, development.explorationair.com, and various other Web sites under the explorationair.com domain.

However, by default, this functionality is disabled in Windows 2000 and requires an updated system DLL. You can get information about the update from Knowledge Base article Q257873, "Error Message: The Name on the Security Certificate Does Not Match the Name of the Site," at http://support.microsoft.com.

Note the following restrictions on how wildcards work in certificates:

  • Wildcards must be situated in the leftmost part of the DNS name. For example, *.explorationair.com is valid; development.*.explorationair.com is invalid.
  • Wildcards cannot be applied to high-level DNS components such as .com or .net. For example, *.explorationair.com is valid, and *.com is invalid.
  • The number of components in the DNS names must be the same. For example, *.explorationair.com will support www.explorationair.com and development.explorationair.com—both of which consist of three name components—but not www.development.explorationair.com.

Figure 9-4 shows the certificate details when the default Web page on https://webserver.explorationair.com is being accessed. The screen shot was taken while the site was being developed and has no content other than the default page warning the site administrator that the site contains no content. Note how the name in the certificate is *.explorationair.com, because this is a valid way of representing webserver.explorationair.com.

click to view at full size.

Figure 9-4. Using a wildcard server certificate in IIS 5.

IP Security

IPSec is a secure version of IP, hence the name. We've already covered the basics of IPSec in Chapter 3, "Windows 2000 Security Overview." IPSec provides privacy through encryption of the data channel between the two computers and provides integrity checking by using cryptographic hash functions.

Although SSL/TLS and IPSec might appear to solve similar problems, they have numerous differences, as described in the next section, that will determine which protocol you should use for securing your servers and your users.

When to use SSL/TLS and when to use IPSec

The decision to use SSL/TLS or IPSec is partly based on the protocol differences. The big variations between SSL/TLS and IPSec are as follows:

  • IPSec secures all IP traffic between computers. SSL/TLS secures only specific protocol traffic, such as HTTP or LDAP.
  • You have no choice over what is protected when using IPSec—everything is protected. With SSL/TLS, you can secure just the parts of your application that require security, such as logon Web pages or credit card entry information. This means that, overall, SSL/TLS is less CPU-intensive than IPSec.
  • Software using SSL/TLS must have built-in support for the protocol. IPSec is transparent to applications.
  • Because IPSec is transparent to applications and SSL/TLS is not, and because SSL/TLS requires applications to have innate knowledge of the protocol, IPSec can be used to secure otherwise insecure protocols such as FTP and Telnet.
  • SSL/TLS relies solely on X.509 certificates for authentication. IPSec uses X.509 certificates, Kerberos, or shared secrets (passwords) for authentication.
  • IPSec does not authenticate users; it authenticates computers. SSL/TLS can authenticate users by using client authentication certificates.
  • SSL/TLS is built into most Web browsers and most Web servers, making it easy to deploy. IPSec is not built into many operating systems.
  • Because of the point raised in the previous bullet, SSL/TLS is well deployed on the Internet. IPSec is relatively new.

Figure 9-5 shows the location of SSL/TLS and IPSec in the TCP/IP protocol stack.

click to view at full size.

Figure 9-5. SSL/TLS and IPSec in the TCP/IP protocol stack.

If you configure your public Web site to require IPSec authentication, privacy, and integrity, chances are good that few users will be able to connect because IPSec is not a common protocol on the Internet at the time of writing. However, there's no doubt this will change over time. If you want to protect sensitive data in transit to and from your Web site, you will need to use SSL/TLS.

If you have a campuswide intranet solution or any environment in which you have control over the client configuration, IPSec is a viable protocol. Indeed, it's probably a good idea to use IPSec because as the population of your user base grows, the population of possible attackers increases also. IPSec mitigates the privacy and disclosure risks by encrypting all data between hosts, including operating system logon data, directory updates, and application traffic.

If you have a business-to-business extranet or a virtual private network (VPN), you should consider using IPSec because all data is protected. SSL/TLS is not designed to work in such an environment; it's designed to protect specific protocols. You can choose between IPSec transport mode between computers—that is, complete end-to-end security at the cost of more complex administration—or L2TP/IPSec tunnels between VPN gateway servers—that is, full security over the Internet and a less complex configuration, at the cost of traffic being exposed on the internal networks at either end of the tunnel. Also, vendors have achieved the greatest interoperability so far in their L2TP/IPSec implementations.

Note that if you have IPSec configured for privacy, you might not need to use SSL/TLS on the Web server unless you use client authentication certificates to require the client to authenticate himself or herself.

A Web server can use both IPSec and SSL/TLS protocols if the server computer has multiple network cards. For example, the Internet-facing network card in a Web server could use SSL/TLS for sensitive Web traffic, and the inner network card could use IPSec to communicate with a server that has a SQL Server database installed. The database server is also configured to use IPSec. In this configuration, only the Web server can communicate with SQL Server.

Figure 9-6 shows a similar scenario, but in this case the scenario includes a management computer also using IPSec. The Web server has three network cards: one listening to unencrypted and SSL/TLS traffic from the Internet, one for management communication, and one for bidirectional communication with the database server. The last two network cards are configured to use IPSec and to communicate with only the management server or the database server.

click to view at full size.

Figure 9-6. A configuration that uses SSL/TLS and IPSec. IPSec is used for authentication and, optionally, privacy between the Web server, management server, and database server.

An issue SSL/TLS and IPSec do not resolve

Getting data securely from the client to the server and vice versa is only half the challenge. What happens to data once it arrives at the server? Some of the data is short-lived and might not be stored on disk. Other data, however, such as credit card, address, and password information, is often stored in databases, where information disclosure and data-tampering threats cannot be ignored. Although SSL/TLS and IPSec do a good job of securing information as it travels from the client to the server and back, they do not secure the data once it is persisted to a database at the Web site.

The SET Protocol

One protocol, Secure Electronics Transactions (SET), designed by VISA and MasterCard, addresses the issue of storing credit card information. Simply put, when this protocol is used, the Web server never learns the credit card details; only the bank involved knows the credit card information. However, SET has not become a popular protocol because it's difficult to implement and it's extremely CPU-intensive.

You can get more information on the SET protocol at http://www.setco.org.

It's imperative that sensitive data be stored securely because of these threats to data stored in databases; data might be disclosed or modified if the database is compromised. Protecting persistent data from attack is our next subject.

Valid Credit Card Numbers for Testing

When testing your Web application, don't use real credit card numbers! Use the following credit card numbers to test your application's credit card privacy; these credit card numbers validate correctly but are not in circulation.

 American Express: 3111-1111-1111-1117 Discover: 6111-1111-1111-1116 MasterCard: 5111-1111-1111-1118 Visa: 4111-1111-1111-1111 

Persistent Data Protection

The persistent data case relates to static data often stored in databases or files. Examples of this include a Web site storing credit card information in its SQL Server database and password information in a browser cache. Storing confidential data in a browser cache or storing user accounts and cleartext passwords in databases is commonplace in many Web applications, and, as we've said repeatedly, doing so creates a huge security vulnerability. One more time: if the Web browser is accessed by another user or if the Web server or database server is compromised, your users' information might be disclosed or modified.

Let's look at both situations: client persistent data security and server persistent data security.

Securing client persistent data

The biggest issue facing Web browsers is caching. Caching is the process whereby a Web browser will store a previously received document, such as an HTML page or JPEG image, with the aim of reusing that document to increase efficiency. In most circumstances, caching is useful and is widely used to provide users with a fast browsing experience. However, when dealing with sensitive information, it's important to realize that under certain circumstances caching is not desirable. For example, if a Web application accepts credit card details and then presents a screen confirming those credit card details back to the user, the browser might cache that document. The cached document is then stored on the hard disk, potentially providing a malicious user with a local file containing the credit card details. For this reason, you need to consider the desirability of caching when working with sensitive data.

The factors determining the desirability of caching are

  • The security of the computers upon which the browsers will be installed
  • The type of users browsing on a shared computer
  • The sensitivity of the information presented by the Web pages with regard to the environment in which the computer is used

If the browser is on a secure computer in a secure environment where only trusted individuals have access to the computer, caching might be acceptable—for example, on a bank computer that employs appropriate security techniques and that can be operated by trusted bank employees only. For a computer in an insecure environment where nontrusted individuals have access, avoid caching. For example, if a Web site is accessible to users at PCs in cybercafes or kiosks, caching confidential or personal information is undesirable.

The following three sections describe techniques for securing sensitive client information; we've presented the techniques in order of decreasing effectiveness.

Avoid sending pages that display sensitive information

The best possible way of preventing documents that contain sensitive information from being cached is to not send such documents to the user. Rather than sending complete credit card details to the user, just send the last four digits, the name on the card, and the expiration date. Also, any errors generated when filling in an HTML form should not result in sensitive information being echoed back to the user in the error response. For instance, suppose a form gathers details regarding a credit card the user holds. If a validation check fails because the card number was not correctly formatted, the correctly entered details should not be sent back to the user along with the error message highlighting the incorrect credit card number. Only point out the error.

There are two possible drawbacks to this solution:

  • Reduced ease of use It is possible that the design and usability of some online forms will be less polished if sensitive information cannot be echoed back to the user. Address this issue by spending some more time on user interface design and by informing users of the benefits of this security approach.
  • Increased application logic complexity When designing a form that does not echo back all user details, it is sometimes necessary to provide logic through which the application can remember all the information. This is technically feasible, but it adds extra complexity to the application.

The technique of avoiding sending sensitive information to the user's browser should be used as widely as possible to help ensure that secure information is never cached.

Prevent sensitive data caching

To prevent a document received by a browser from being written to the cache, make sure the page contains the appropriate HTML tags. Unfortunately, only HTTP 1.1 supports a directive to instruct a browser not to cache a file. HTTP 1.0 provides no support for instructing a browser not cache a file. In response to this issue, some browsers based upon the HTTP 1.0 standard implement various nonstandard techniques to instruct the browser not to cache pages. Because Internet Explorer 5 supports HTTP 1.1, it can be instructed not to cache data. Internet Explorer 4 supports a technique utilizing HTTP 1.0 commands over an SSL/TLS connection to instruct the browser not to cache documents.

Techniques to prevent caching are covered in the section "Anticaching techniques," which appears below.

Avoid displaying previously cached data

If a browser has previously cached some information, perhaps because it did not respect or understand a caching directive, it's important to ensure that the information is not revealed to users of the browser, who may or may not be the user who requested the sensitive information. Both HTTP 1.0 and HTTP 1.1 support techniques for informing a browser of the appropriate time in which to keep a cached item before considering it to be expired or stale. When a user requests a cached page that is considered expired, the browser will contact the server to request the document rather than display the cached version.

You can reduce the chance of cached information being displayed by ensuring that all documents are marked as "expiring immediately." Documents marked as expiring immediately will not be displayed by a browser that respects the expiration information, but the documents might be held in the local hard disk's cache for a short period. During this time, the files are still vulnerable to attack. For this reason, this technique is the least desirable anticaching technique.

NOTE
Internet Explorer 5 does not refresh pages when the Forward and Back buttons are used. Pages are always pulled from the cache. The behavior of Forward and Back was changed to conform with the HTTP 1.1 specification.

Techniques for marking documents as expired are discussed in the next section.

Anticaching techniques

To ensure minimal caching of sensitive information, use the following techniques on pages that display sensitive information:

  • Use SSL/TLS. Ensure that all documents and images that include sensitive information are delivered using the SSL/TLS protocol. This will prevent proxy servers and firewalls from caching the data. By default, Internet Explorer 4 and Internet Explorer 5 will not cache pages accessed when SSL/TLS is used.
  • Set caching directives. Add the following lines of code to the top of all ASP pages dealing with sensitive information:

 <% Response.AddHeader "Pragma", "no-cache" Response.Expires = -1 Response.Cache-Control = "no-store" %> 

Table 9-3 details the effects of the directives in the preceding code.

Table 9-3. HTTP headers that prevent browser caching.

Cache Header Comments
Pragma:no-cacheInstructs HTTP 1.0 proxy servers to not cache the Web page.

Internet Explorer will not cache a Web page accessed using SSL/TLS when this header is in effect.

Response.Expires Instructs browsers that do cache pages to request a new page from the Web server rather than use a cached copy
Cache-Control:no-store Instructs Internet Explorer 5 not to cache the Web page, even when using the Back and Forward buttons. This option instructs HTTP 1.1 proxy servers to not cache the Web page.

NOTE
It's recommended that you do not use Cache-Control:private, because this directive specifies that information can be cached on a per-user basis. Including this directive might override the no-cache directive.

Internet Explorer and AutoComplete

Internet Explorer 5 provides a feature called AutoComplete that saves users from repeatedly typing frequently requested details into HTML forms. The AutoComplete feature saves previous entries you've made for Web addresses, forms, and passwords. Later, when you type information in one of these fields, AutoComplete suggests possible matches. However, if a user accesses a Web site, enters a password, and opts to save the password by using AutoComplete, another user using the same machine and same user identity could navigate to the same Web site and the password might be automatically filled in by the browser.

You can disable this capability by performing these steps:

  1. Open Internet Explorer.
  2. Choose Internet Options from the Tools menu to display the Internet Options dialog box.
  3. Click the Content tab.
  4. Click the AutoComplete button.
  5. Disable the options you don't want to support.
  6. Click OK, and then click OK again.
  7. Figure 9-7 shows the AutoComplete Settings dialog box.

    click to view at full size.

    Figure 9-7. Configuring AutoComplete settings in Internet Explorer 5.

As a Web site developer, you can force sensitive form fields or an entire form to disregard AutoComplete by setting the AUTOCOMPLETE attribute to Off. The following HTML code shows the attribute:

 <FORM method=POST action="submit.asp" AUTOCOMPLETE="OFF"> 

Disable AutoComplete on per-field basis like so:

 <input type="text" name="txtCreditCard" value="" size="16" maxlength="16" AUTOCOMPLETE="OFF"> 

Privacy issues with Basic and Digest authentication

When a user first connects to a Web server that requires Basic or Digest authentication, the user is presented with a dialog box in which to enter credentials. From that point on, the Web browser automatically sends the appropriate credentials to the Web server so that the user does not have to reenter them. The security threat is simple: as long as the browser is not shut down, it will continue to send the user's credentials to the Web server. Hence, a malicious user could navigate to the Web site and use the first user's credentials without entering them!

The best way to counter this threat is to close the browser, but you can offer another solution to this in Internet Explorer by creating a COM+ control that contains code like the following and calling it from client-side Microsoft Visual Basic, Scripting Edition (VBScript) or JScript:

 STDMETHODIMP CInternetStuff::EndSession() { HRESULT hr = S_OK; DWORD dwError = 0; // End the session. if (!InternetSetOption(NULL, INTERNET_OPTION_END_BROWSER_SESSION, NULL, 0)) { dwError=::GetLastError(); hr=HRESULT_FROM_WIN32(dwError); } return (hr); } 

Refer to Knowledge Base article Q195192, "HOWTO: Clear Logon Credentials to Force Reauthentication," for further details on this functionality.

Now let's turn our attention to the other side of the Web connection, the server.

Securing server persistent data

Because they hold so much juicy data, your Web and database servers must be protected from privacy and integrity attacks. Data held in files or in the Registry on the server must be secured using appropriate ACLs. For extremely sensitive data, you should consider the Encrypting File System (EFS). With EFS, only an entity that holds a decryption key can decrypt the encrypted files, and the chances are slim that an attacker will have such a key. For example, SQL Server accesses its database files as the identity used to start SQL Server, not as the calling user. If you use EFS to encrypt database files, you must do so as the identity used to start SQL Server. From then on, only SQL Server can access the data files—every other attempt to access the database files by an attacker will fail unless the attacker can log on as the account used to start SQL Server.

Storing passwords at the server

It is the authors' contention that end users want a high degree of privacy and security as they browse the Web and purchase services and items. To that end, some users employ a startling array of passwords and user accounts to access personalized areas of their favorite Web sites. Unfortunately, many people forget their passwords and as a result use only one password for multiple Web sites, which is definitely a problem. If a Web site is successfully attacked and the user's password is disclosed, chances are good that the password can be used elsewhere on secure Web sites frequented by the user. Another serious problem is the case of a rogue Web site administrator. If he can access a user's password, he might attempt to access other Web resources by using the user's credentials.

You should counter these particular threats by storing a hash of the password rather than the cleartext password at the server. When a user connects and enters her password, your application can derive the hash of the password and compare the hashes. If the site is compromised, the attacker will get the hashes, not the passwords, and it's infeasible to determine a password knowing only the hash. We covered the concepts of storing hashes and salting hashes in Chapter 8, "Practical Authentication and Authorization."

This solution creates a usability issue, however. As we've already mentioned, users forget their passwords. To remedy this, many Web sites store the password and a password hint question. Either you click a button on the Web site to get your password e-mailed to you or you ask the Web site to give you the password hint. Hopefully, the hint is good enough for you to remember your password. For example, if your password is "S1riu$" and your hint is "a canine star," will you think of stars in the constellation Canis Major rather than Lassie, the canine film star? Password hinting isn't such a bad idea, so long as the cleartext version of the password is not maintained by the server. (It's also dangerous to send cleartext passwords in e-mail to the user. The e-mail could easily be read as it travels from the Web site to the user.) Also, make sure to avoid obvious hints—never use a hint like "capital city of England."

While we're on the subject of hints, please do not ask for the maiden name of a user's mother. This is virtually public information and of little security benefit.

NOTE
A cursory query by the authors for the exact phrase "password hint" in a popular search engine found over 42,000 Web sites that support a password-hinting feature.

A solution to storing cleartext passwords

Just say no to maintaining cleartext passwords unless you absolutely need to keep the passwords for alternate authentication purposes other than the initial logon to the Web site. If you must store cleartext passwords, offer your clients a service: sending their passwords to them in secure, encrypted e-mail, by using Secure/Multipurpose Internet Mail Extensions (S/MIME). For you to be able to do this, the client must have a client authentication certificate or an e-mail certificate, which can be obtained from many certification authorities, such as VeriSign ( www.verisign.com) or Thawte Consulting ( www.thawte.com).

The process works like this:

  1. When the user signs up to use the service provided by your Web site, you can offer the option to provide secure password notification in the event the user forgets the password. This could also be an option on the user's account maintenance pages.
  2. Selecting this option links the user to a page explaining that you require a client authentication certificate from the user. The certificate will be stored by the Web site in a secure database. However, there's nothing to fear because a certificate is public information. The user is then given the option of continuing or returning to the original page.
  3. If the user chooses to continue, the link goes to a virtual directory that requires a client authentication certificate issued by one or more certificate authorities (CAs) you trust.
  4. The user's browser prompts the user to select a client authentication certificate.
  5. When the user selects the certificate and the rest of the SSL/TLS negotiation completes, the ASP page will have access to the client's certificate through the Request.ClientCertificate("Certificate") information.
  6. The ASP page writes the client authentication certificate into the database alongside the user's information.

When the user notifies the Web site that she has lost her password, the following process occurs:

  1. The user's password and client authentication certificate are retrieved from the database.
  2. Using COM+ components such as AspEncrypt and AspEmail from Persits Software (www.persits.com), you construct a S/MIME message addressed to the e-mail name in the user's certificate and encrypted using the public key in the user's certificate. Because the user receiving the e-mail is the only person with the associated private key, only that user can decrypt the message.

The following sample ASP code will build an S/MIME response containing the user's password. It's assumed that the password and client certificate have already been retrieved from the database.

 <% ' strPassword and blobCert ' already taken from the database. ' Instantiate various COM+ components. Set oMail = Server.CreateObject("Persits.MailSender") Set oCM = Server.CreateObject("Persits.CryptoManager") Set oContext = CM.OpenContext("emailcontainer", True ) ' Extract e-mail name from the certificate. Set certClient = oCM.ImportCertFromBlob(blobCert) strEmail = certClient.Subject("E") If strEmail <> "" Then Set oMsg = oContext.CreateMessage(CBool(0)) ' Associate certificate with message. oMsg.AddRecipientCert certClient ' Build and send the encrypted message. oMail.Host = "mail.exair.com" oMail.Subject = "ExAir Password" oMail.From = "accounts@exair.com" oMail.FromName = "User Accounts" oMail.AddAddress = strEmail oMail.Body = "Your secret password is " & strPassword oMail.SendEncrypted Msg Response.Write "Message successfully sent to " & Email Else Response.Write "Certificate does not contain an" & _ " Email address." Response.Write "Message Not Sent." End If %> 

This simple piece of code will send a secure e-mail message to the recipient. Because the e-mail cannot be decrypted by an attacker, the user's password is secure.

While we're on the subject of ASP code, let's turn our attention to a way of mitigating a threat on the mind of all security-conscious Web developers: illicit access to Web source code.

Obfuscating ASP code

A risk faced by all Web servers is an unforeseen information disclosure vulnerability that yields access to the server-side code, such as ASP or CGI, to the wrong people. For example, incorrectly set ACLs might allow an attacker to read the contents of your ASP applications when they should not be able to. Because of this, you should never store passwords, usernames, or other private information in server-side code. Including such information should be deemed a major security risk, and appropriate risk mitigation plans should be put in place in case the script is accessed by an attacker.

One such way to alleviate, but not fully mitigate, this risk is to use script encoding. Script encoding is a feature of the Microsoft script engines, including VBScript and JScript. The Microsoft Script Encoder, Screnc.exe, is a command line tool that enables ASP developers to encode their script so that other users cannot view or modify their source. Note that this encoding prevents only casual viewing of your code; it will not prevent a determined hacker from accessing the code. For example, the following two code samples from the Exploration Air example query a SQL Server database to get flight timetables; the code in the first sample is not encoded and the code in the second is. If an attacker accessed the cleartext ASP code, he would learn the name of the database server, DBServer.ExplorationAir.com. He could then use this information to probe for vulnerabilities that gain access to the database server.

First, here is the cleartext version:

 <% ' Copyright (c) 1999-2000, Exploration Air. All rights reserved. ' **Start Encode** ' Open the database connection to get flight timetable. ' Only valid users can do this, based on permissions in ' SQL Server. Dim oDB Set oDB = Server.CreateObject("ADODB.RecordSet") oDB.Open "{call spCurrentTimeTable}", _ "Provider=SQLoledb;" & _ "server=DBServer.ExplorationAir.com;" & _ "initial catalog=ExAir;" & _ "Trusted_Connection=Yes", _ 0, 1 ' Hoist the variables from the loop to increase performance. Dim fldFrom, fldTo, fldDepartTime, fldArriveTime Set fldFrom = oDB("fldFrom") Set fldTo = oDB("fldTo") Set fldDepartTime = oDB("fldDepartTime") Set fldArriveTime = oDB("fldArriveTime") Response.Write "<TABLE>" Do while Not oDB.EOF Response.Write "<TR>" Response.Write "<TD>" & Trim(fldFrom) & "</TD>" Response.Write "<TD>" & Trim(fldTo) & "</TD>" Response.Write "<TD>" & Trim(fldDepartTime) & "</TD>" Response.Write "<TD>" & Trim(fldArriveTime) & "</TD>" Response.Write "</TR>" oDB.MoveNext      Loop Response.Write "</TABLE>" oDB.Close Set oDB = Nothing %> 

And this is the abbreviated encoded version:

 <%@ LANGUAGE = VBScript.Encode %><% ' Copyright (c) 1999-2000, Exploration Air. ' All rights reserved. '**Start Encode**#@~^TgQAAA==@#@&dv,ra+x,Y4nP9lOl(ldn,m U+1YkKU~YKPT+OPWsbo4Y,Oks+OC(V+@#@&iB~rsHP-mVbNP!/q./,m Cx,NG~DtkkSP(l/a[~WPa+.:rdkkGxk~kPj}dP?n.7+.@#@&7Gkh, WGA@#@&dUnY,W9A,'~jqD\q.R;D+mOnr(L3mO'E)Gr9Ac]+1W.[U+YEb @#@&7WG$cr21x,J1l^sPkw/EMDnUDKksnKm4VNE~,{@#@&7d~EhDG\b  0s[:WP~x,Dd'rW^NPKJ*@#@&i?fOP6V[fvwC.DKksnP,'PMdcJ6V9fn wC.DKr:@E#@#@&7jeYPWs9b.Db-fKrs+,P',DkcJ6V[bMDr-9KksnJ* @#@&@#@&7I5/aWU/n /nRq.bYn,J@!zKzAd3@*r@#@&@#@&dG9~RZ^G /3P@#@&7j+DPKf$Px~WOtbUo@#@&hy0BAA==^#~@%> 

The overhead of performing the decoding phase is minimal because the appropriate script engine decodes the encoded script file when IIS loads the file for the first time. IIS then caches the decoded script, and there's no longer a performance penalty.

You can find out more about script encoding at http://msdn.microsoft.com/scripting.



Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
ISBN: N/A
EAN: N/A
Year: 1999
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net