An Introduction to Threat Modeling

Web Service Security Technologies

The third phase of the threat modeling process involves choosing appropriate technologies to apply the threat mitigation techniques you have chosen. Before I describe specific technologies, let's take a look at what the current Web service infrastructure provides in the way of security features.

As of this writing, the primary communication protocol used by Web services, SOAP, does not define security protocols; it relies on the Web server, and potentially the client application, to provide those services. The main reason for this is that SOAP is transport independent; Web services use HTTP as a transport, but other SOAP-based services might use SMTP or other technologies as a transport. This can be problematic if your threat model determines that the data must be secure as it travels from the client to all back-end servers.

Let's look at an example, which is depicted in Figure 10-2. The client communicates with a Web service, and the service determines that it will protect the client data using SSL or TLS as the data moves between the client and the Web service. It will then send the client data to a back-end service that uses sockets as a transport.

Figure 10-2 A scenario using SSL or TLS to protect client and server data.

Can you see where the problem is? The protection provided by SSL/TLS applies only to the link between the client and the server, not to the link between the server and the back-end application server. In many instances, this might not be an issue. However, if you determine in your threat modeling that information disclosure threats exist as data leaves the Web service and the back-end server, SSL/TLS will not work. Even if the data is reprotected using SSL/TLS between the Web service and application server, it will remain in cleartext for a nonzero amount of time at the Web service and might be viewed by a user at the server. (Of course, you should trust the people administering the Web service!) Once again, this might be a risk you are willing to live with, but your decision should be based solely on your threat modeling.

Now that you have a basic understanding of the security features that the current Web service infrastructure provides, let's look at some ways to apply security technologies appropriately.

Web Services Authentication

Authentication is the ability to prove that an entity—for example, a user or a computer—is who it claims to be. You can verify this claim by having the entity, also called a principal, provide credentials. Credentials often take the form of a username and a password. Note that some authentication protocols are more secure than others—you can be more certain that the credential really came from the correct user and was not replayed by an attacker. A Web service running on top of IIS has a number of authentication protocols available to it, most notably

• Anonymous authentication

• Basic authentication

• Digest authentication

• Windows authentication

• Certificate-based authentication

• Forms-based authentication

• .NET Passport authentication

Let's look at each in detail.

Anonymous Authentication

Anonymous authentication is just that—anonymous. No authentication takes place. This is the authentication mechanism you would use for public data. You do not need to update or add any code to your SOAP client because no authentication is taking place.

Basic Authentication

Basic authentication is probably the most common form of authentication on the Internet because of its simplicity. It is provided by every browser on every platform. It is also insecure because the username and password are sent on every request from the client to the server in the clear—the data is not encrypted. This means that you must use some form of channel encryption to protect the username and password from disclosure to malicious users. Of course, you technically do not have to encrypt the channel if you do not care whether the username and password are disclosed. And, frankly, this might be fine if your Web service serves nonconfidential data such as stock information or news headlines. There is a difference between using authentication as a means to protect access to data and using authentication as a means to identify users to give them the personalized content they require. Once again, you should use threat modeling to determine whether basic authentication is good enough for your application.

In IIS 5 and 6, accounts used for basic authentication must be valid Windows accounts. However, when basic authentication is used by ASP.NET or, by inference, is used by a Web service written using ASP.NET, you can use a database lookup to determine whether the credentials are correct. You can set basic authentication within the IIS administration tool.

If you use basic, digest, or Windows authentication, you can set the username and password in a SOAP client, as shown in the following VBScript code:

Set sc = CreateObject("MSSoap.SoapClient") sc.mssoapinit("http://www.fabrikam.com/webservice/service.asmx?wsdl") sc.ConnectorProperty("AuthName") = "username" sc.ConnectorProperty("AuthPassword") = "password" Status = sc.GetShippingStatus("10001")

If you wrote your client-side application using C++ and the ATL SOAP classes, you can set the username and password in the CAtlHttpClient:: AddAuthObj method. If your client code is written in C# or another managed language, such as Visual Basic .NET, you can use code such as the following to create an authenticated connection to the Web service. (This code will work for basic, digest, and Windows authentication.)

using System; using System.Net; using System.Web.Services.Protocols; ClientApp.localhost.Service s = new ClientApp.localhost.Service(); s.Credentials = new NetworkCredential(username, password, domain); string shipped = s.GetShippingStatus("10001");

In the overall scheme of things, basic authentication is incredibly weak, especially when SSL/TLS is not employed.

Digest Authentication

Like basic authentication, digest authentication is an Internet standard; both are described in RFC 2617 at http://www.ietf.org/rfc/rfc2617.txt. However, unlike basic authentication, digest authentication is not common because the only browsers that support digest authentication are Internet Explorer 5 and later. Digest authentication does not transfer the user's password in the clear; instead, a hash, or digest, of the password and data provided by the server is used to authenticate the user. Digest authentication is certainly a little more secure than basic authentication, and it has the added advantage that you do not need to use SSL to hide the user's password. But as I said, it is only a little more secure. Note also that digest authentication works in IIS 5 and 6 only if Active Directory is installed because Active Directory can be configured to store an encrypted plaintext copy of the user's password, which is required by digest authentication.

As with basic authentication, you can use the IIS administration tool to configure the Web server to require digest authentication.

Windows Authentication

As the name implies, Windows authentication uses authentication mechanisms built into Windows. From Windows 2000 on, this means NTLM and Kerberos. Kerberos authentication is applicable only when Active Directory is employed. The main downside to Windows authentication is that it does not work well across the Internet, but it is an exceptional intranet solution because it can use the user's logon information directly, without necessarily prompting the user to enter a username and password. Also, the password is never sent across the wire in plaintext.

Windows authentication can be configured like any other protocol, but in the case of ASP.NET Web services, you can opt for Windows authentication by adding the following code to the web.config file:

<authentication mode = "Windows"> </authentication>

You can also force ASP.NET to impersonate the calling user with the following web.config configuration entry:

<system.web>   <identity impersonate="true" /> </system.web>

You can then get the name of the calling user by using the following code in your Web service:

using System.Security.Principal; WindowsIdentity wi = WindowsIdentity.GetCurrent(); string name = wi.Name;

Certificate-Based Authentication

Certificates use large private keys rather than passwords to determine the principal's identity. Before I delve into how and why you would use certificates, let's take a quick detour through the technology behind certificates. Unlike symmetric key encryption, which uses a single key to encrypt and decrypt data, certificates use asymmetric encryption, also called public key encryption. When a certificate is created, two large keys are created, a private key and a public key. The former, as the name implies, is private and should be protected. The latter, the public key, can be made public and is embedded in the certificate, which contains information about the private key owner.

Public key cryptography also has the following important attributes:

• Data encrypted with the public key can be decrypted only using the private key.

• Data encrypted with the private key can be decrypted only using the public key.

If you have a private key, you can send authenticated messages to others. In other words, the recipient can prove that you sent the data. This is because you encrypt using the private key, which only you own; it is private, and only the public key can decrypt the message. The public key is in your certificate, which includes details about you, so you must have sent the data.

The process of encrypting using a private key is also called signing. If you have someone else's public key, you can send that person encrypted messages. Actually, the process of signing is a little more complex than that—the data itself is not signed, but a hash of the data is signed, for the sake of speed.

Most certificates today use a cryptographic algorithm called RSA, the U.S. patent for which expired in September 2000.

	Some trivia: The RSA algorithm uses large prime numbers when creating its keys. The now-expired patent number for RSA is 4,405,829. It is a prime number!

When you use SSL/TLS, the session between the client and server is protected from prying eyes using symmetric encryption. However, the server is also authenticated. When you visit the Barnes & Noble bookstore on line at http://www.bn.com and you go to check out, an SSL/TLS session is established. During the handshake, the name of the Web site you are browsing is compared with the name in the certificate to determine whether the server can correctly decrypt random data provided by the client after it is encrypted with the site's public key from the certificate. If the site can decrypt the blob, the site must have the protected private key associated with the public key in the certificate. Also, the date validity is verified in the certificate. If all these steps succeed, the server is authenticated and the user knows she is communicating with the real Barnes & Noble Web site, not an imposter.

The good news about SSL/TLS is that it also supports an optional client authentication process. In this case, the server tells the client application to provide a certificate and to decrypt a blob that was encrypted using the public key in the certificate. After some other (we can hope successful) checks, the client is also authenticated. SSL/TLS client authentication is an optional step in the SSL/TLS connection process and is in fact rarely used except in very secure environments. In exceptionally secure environments, certificates and private keys can be stored on smart cards.

You can force the SOAP client to use a specific client certificate by using the following construct when you use the Microsoft SOAP Toolkit:

sc.ConnectorProperty("SSLClientCertificateName") = "[e-mail]"

You should specify the common name (CN) part of the certificate's subject name. Note that if you have more than one certificate with the same subject common name, the first will be chosen.

If your client code is written using the Visual Studio Web Reference Proxy code (which is generated after you make a Web reference), you can set the client certificate using the service's ClientCertificate collection. Note that you currently cannot access a certificate in a CryptoAPI (CAPI) store in the same fashion that the SOAP Toolkit code can; you must use a certificate file.

Forms-Based Authentication

Forms-based authentication is not an industry-standard way of authenticating users, but the method is very popular. Forms-based authentication generally refers to a system in which unauthenticated requests are redirected to an HTML form using HTTP redirection. The user provides credentials (username and password) and submits the form. If the application authenticates the request by performing a database or XML file lookup, the user is granted access.

Forms-based authentication uses HTML pages, so it is not supported by Web services because Web services have no UI. However, ASP.NET does support forms-based authentication.

.NET Passport Authentication

.NET Passport is a centralized authentication service provided by Microsoft that offers a single sign-on and profile services for member sites. This benefits the user because she no longer has to log on to access new protected resources or sites. If you want your site to be compatible with Passport authentication and authorization, this is the provider you should use. For more information, see the Passport documentation at http://www.passport.com/business.

Because Passport authentication uses cookies, it is not currently supported by Web services. However, this will change. ASP.NET does support Passport authentication, as does IIS 6.

A full explanation of the IIS 5 authentication techniques is available in Designing Secure Web-Based Applications for Microsoft Windows 2000 by Michael Howard (Microsoft Press, 2000).

Web Services Authorization

Once your application identifies a principal by using an authentication mechanism, it needs to determine whether the user has access to the various resources your service protects and can call specific functions. Windows 2000 and later offer numerous ways to authorize access to resources, with the most prolific and important being ACLs.

Windows NT and later protect securable resources (such as files) from unauthorized access by employing discretionary access control, which is implemented through discretionary access control lists (usually abbreviated as ACLs rather than DACLs). An ACL is composed of a series of access control entries (ACEs). Each ACE lists a principal and contains information about the principal and the operations that the principal can perform on the resource. For example, some people might be granted read access and others might have full control.

ACLs are quite literally your application's last backstop against an attack, with the possible exception of good encryption and key management. If an attacker can access a resource, her job is done. Therefore, it is incredibly important that you have appropriate ACLs on the resources you protect. For example, should all users (also called Everyone) have full access to a sensitive file? Probably not, but certain users might.

The real beauty of ACLs is that they are always enforced the same way regardless of the access mechanism. So, if for some reason an attacker can bypass your service and hence circumvent application-level authorization logic and access a resource directly, the authorization policy in the resource's ACLs will still be enforced.

A little higher up the application layer is authorization in ASP.NET and within your application, or within the database permissions (assuming you are using a database).

ASP.NET offers a rich smorgasbord of authorization techniques; deploying such policies is as simple as setting an XML property. For example, you can restrict access to a portion of your Web service so that anonymous users are disallowed by adding the following to the web.config file:

<authorization>   <deny users="?" /> </authorization>

In this case, ? means anonymous users and * means all users. You can also allow specific users using <allow users="name" />, where name is one or more names separated by commas.

Web Services Privacy and Integrity

When you think about privacy and the integrity of SOAP data, remember that there are two aspects to both technologies. The first aspect is securing the channel between the client and the Web service, and the second is securing the SOAP payload or data within the payload—not only as it travels from the client to the Web service and vice versa, but also when the data is persisted to some form of persistent data storage. The former scenario is well understood and is easily handled with no code modification by using SSL/TLS or IPSec. Because these protocols are below the application layer (the layer in which your service resides), they are completely transparent. A simple switch in the Web server, and voila!—you have a connection protected with SSL/TLS.

Presently, there is no standard way to encrypt SOAP messages or to provide for the integrity of the payload data. This is especially true if you want to allow any client to connect to your service, in which case you must support a standard way to achieve these goals. These standards are currently being designed. You can read more about future directions in the section titled “Future Web Service Security Technologies” later in this chapter.

So what happens if you want to roll your own encryption or integrity mechanism? You can do this if you have control over the client code and the server code because you can determine what the data formats will look like. You can find a very simple example of doing this with SOAP extensions at the MSDN site (http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp09272001.asp). However, as of this writing, the code uses a hard-coded key to encrypt and decrypt the data using Data Encryption Standard (DES). If you plan to use the code in your SOAP application, you should store the key elsewhere on the computer, such as in the registry or in a protected XML configuration file (protected meaning that the file is not easily accessible through the Web server and is protected using good ACLs) and not in the source code itself. When you design systems using custom encryption, key management is a very hard problem to solve. One way around this is to use SSL/TLS to transfer the key from the server to the client. (Do not let the client determine the key—an attacker might choose a weak key!) Then perform communication in the open but encrypt the appropriate SOAP data.

You can determine whether a SOAP method is invoked over a channel secured using SSL/TLS by using the following code:

if (HttpContext.Current.Request.IsSecureConnection) {     // Connection is using SSL/TLS. } else {     // Connection is not using SSL/TLS. }

This code will not detect whether IPSec is used to protect the channel between the client and server. In fact, there is presently no way to determine this easily from the managed environment.

While we are on the subject of keys, if you need to generate good-quality random data, such as that used to create an encryption key, do not use the Random class—it is highly predictable. Instead, use code such as this, which creates 32 bytes of highly random data:

using System.Security.Cryptography; byte[] b = new byte[32]; new RNGCryptoServiceProvider().GetBytes(b);