Securing Web Services

It helps to know a little about the reasons behind the development of Web services before you delve into the security issues associated with this technology. You can use technologies such as DCOM and CORBA in an Internet environment. In fact, these technologies offer many features that Web service technologies such as SOAP don’t offer. DCOM can automatically encrypt your communication so that it isn’t readable by anyone else. It also provides the support needed to validate the data and authenticate the user. DCOM and CORBA are both inherently more secure than any Web service communication, even with the latest security features for Web services installed on your system. In addition, both DCOM and CORBA are heavily tested and mature technologies that developers understand well. The fact that developers truly understand these technologies also helps make them more secure—you can’t create a secure application if you don’t understand the underlying technology.

The problem with using DCOM and CORBA is that they’re incompatible. An application that relies on DCOM can’t communicate with an application that uses CORBA. In addition, both technologies are binary. Even if you can locate the data stream, it’s unlikely that any virus scanning software could find a hidden virus because the data stream is unreadable. It’s also impossible to use a firewall. DCOM requires so many open ports that any firewall you set up is going to be useless. In short, even though DCOM and CORBA are secure from a data perspective, they have problems that a developer can’t easily fix in a distributed application environment.

Tip

Microsoft is obviously interested in promoting their new Web services, so their marketing machine is pumping out the usual flood of interesting documents. Cutting through the hype can be difficult. However, you’ll find a technically solid article on the topic entitled, “Using Web Services Instead of DCOM” at http://msdn.microsoft.com/library/en-us/dndotnet/html/webservicesdcom.asp.

Web services are secure to a point. You can use a single standardized port for communication, which means firewalls remain effective. Web services rely on pure text data transmission, so you don’t have to consider weird programming strategies to ensure compatibility. The use of standardized communication tends to make the application more secure as a whole. However, the text-based nature of Web service communication leaves your data completely unprotected. The lack of data security, user authentication, validation, and other security needs all conspire to make Web service solutions inherently non-secure. The following sections describe these problems in greater detail and offer solutions for resolving them.

XML and Security

XML is an important part of the security efforts for distributed applications. The need for security is greater in distributed applications than in desktop or LAN applications, yet security efforts have lagged in the distributed application arena. Many companies cite the lack of good security as one of the main reasons their distributed application plans are on hold, so, obviously, the computer industry has to do something to address the problem.

The Worldwide Web Consortium (W3C) and Internet Engineering Task Force (IETF) released the XML Signature specification as an industry standard shortly after the release of Visual Studio .NET. This means you won’t find this important security feature as part of Visual Studio .NET until Microsoft adds it as a service pack or part of a subsequent release.

XML security is an important issue because the standard XML transmission relies on pure text, which means data is open to the casual observer. Using an XML Signature means that the recipient can validate the XML data sender and verify that the data is unmodified. Look for third party vendors to offer products that add XML Signature support to Visual Studio .NET. You can read about this standard at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/. The W3C and IETF are still working on two other XML security standards: XML Encryption and XML Key Management.

The use of biometrics is also becoming an important part of local application security. Biometrics make it difficult for a third party to steal passwords because the password is based on a body feature such as a fingerprint, facial component, voiceprint, or the construction of the iris. Previous biometric encoding techniques relied on binary technology, which doesn’t work well with XML—a text-based technology designed to overcome the limits of binary data transfer. The XML Common Biometric Format (XCBF) is a new standard designed to make biometrics accessible to XML communication. You can see an overview of this technology at http://www.eweek.com/article/0,3658,s=1884&a=23693,00.asp, http://www.infoworld.com/articles/hn/xml/02/03/07/020307hnoasis.xml?0308fram, and http://www.internetnews.com/dev-news/article/0,,10_987001,00.html. You can find a more comprehensive discussion of this topic at http://www.oasis-open.org/committees/xcbf/.

Web Service Proxy Security Considerations

A Web service works like the other remote code strategies that came before it in one important way—the component executes on the host machine, not the client machine. The client machine receives a proxy—a representation—of the Web service to use locally. The host machine has a stub—a representation of the caller—to use in most cases. Consequently, you aren’t working with an actual object on your system when you perform a Web service call.

Tip

If you wonder how the security of the Web service functionality provided by the .NET Framework compares to other platforms, at least one study on the subject is in. According to an eWeek article (http://www.eweek.com/article2/0,3959,1113313,00.asp) an @Stake study confirms that the features provided by the .NET Framework are a little better than those provided by IBM’s Websphere. The article states that neither company had any input into the test to ensure @Stake conducted the test in the fairest manner possible. Although this speaks highly of Microsoft’s efforts, it’s always important to consider the basis for such tests and whether they reflect the realities of your installation.

Both the client and the server experience some level of risk when using a proxy/stub setup to perform communication. In fact, it doesn’t matter which technology you use for communication—the risks are the same. However, the probability of a security breach due to these risks is much greater in a Web services environment due to the use of a text-based communication media. Here are the security risks you should consider.

Query Contamination

Web services are self-describing—your program sends a request and the Web service returns an XML document that describes the service. You can list many benefits to this approach, such as the ability to locate and use a component even when the component lacks registry information on the local machine. DCOM required such information, making the technology less than useful in a distributed environment of the kind provided by the Internet. However, the self-describing nature of Web services can also cause security problems. To learn about the component, an application must send a query. The act of making a query and allowing return information opens the door to cracker attack.

Warning

Some developers have the misinformed opinion that viruses can’t reside in XML because XML is just text. Actually, XML is formatted text—it includes tags and other information. Yes, you can read XML, but most people use a parser to interpret the tags and present the information in a more readable form. The moment you use a parser on any text, you add the potential for a virus. For example, Rice University has a Web site containing its latest virus to test student code for the COMP 314 course where they learn to write an XML parser (http://www.owlnet.rice.edu/~fnjord/output/article17.html). In fact, the addition of XML support to products such as Office 2003 could slow adoption of these products according to a ComputerWeekly.com article (http://www.cw360.com/Article120453.htm). Even Microsoft acknowledges that viruses in XML are a significant threat and provides a free XML filter for their Internet Security and Acceleration (ISA) Server (http://www.microsoft.com/presspass/features/2002/feb02/02-18xmlfilter.asp). To put the threat into perspective, a Network World Fusion article states that at least one virus already targets .NET applications through Web services (http://www.nwfusion.com/news/2002/0110donut.html). In short, running Web services represents a significant security threat that you must consider carefully.

Data Security and Data Validation

Text-based communication means that there’s no way to ensure the data is the same data that the other party transmitted. Everything from acts of nature to a cracker’s intervention could modify the data. Consequently, you can’t trust any data you receive unless you provide some type of security of your own. Yes, using Secure Sockets Layer (SSL) does help, but the flaw is in the data itself. This use of text means a Trojan or virus on either machine will remain undetected (or is at least harder to detect).

Channel Security

A cracker’s best hope of remaining undetected is to intercept the data between sites. Intercepting the data isn’t as hard as you might think. All the cracker needs is a relatively inexpensive packet sniffer and an IP address. It doesn’t take long for the cracker to determine which port to use, which means your data is completely exposed. SSL is a good deterrent for channel problems and you should always use it with Web services.

User Authentication

Chapter 10 discussed a number of user authentication issues and strategies. For example, the “Using SSL to Communicate Credentials” section discusses how you can learn more about a caller by checking the SSL credentials. The problem with this approach is that it assumes the caller has credentials—many don’t. In addition, it also relies on your trusting both the Credential Authority (CA) and the caller possessing the credentials. In short, even with credentials, user authentication can become difficult. Of course, standard user authentication assumes you know the caller—it’s quite possible with a Web service that you won’t know anything at all about the caller, which makes authentication nearly impossible.

Caller Location

Sometimes the best checks are the ones that you can implement with the fewest number of problems and the least amount of code. The “Using Principal and Identity Objects” section of Chapter 4 shows how to check the caller’s zone (or location). If you expect a caller to make a request from the intranet and suddenly a request comes from the Internet, you have to question the sudden change. You can verify this information using the ZoneIdentityPermission attribute—a single statement can save you some security headaches.

Third Party Intervention

Third parties are an increasing threat for Web services. A third party could simply listen to the conversation and record everything for future blackmail. In fact, an InfoWorld article (http://www.infoworld.com/article/03/05/23/21secadvise_1.html) points out that cracking is now one of the strategies organized crime uses. Third parties can also modify the data, erase it completely, interfere with its transmission, and perform other nasty deeds. Given the number of third party threats, it’s amazing that Web services work at all.

Most developers don’t work with third party Web services today. The developers who do work with third party Web services usually know the third party and can trust them. If Web services continue in their current direction, you might not know the third party in the future. The problem with this lack of knowledge becomes clear when you consider what happens when you connect to another machine looking for a Web service to use. Visual Studio .NET creates a proxy of that Web service on your local machine using your trusted user’s account. Any virus code or Trojan that the third party installs in the Web service could also affect your machine. Always exercise caution when creating a reference to a third party Web service in your application.

Working with SoapHttpClientProtocol Class Security

The Visual Studio .NET IDE performs a lot of the work required to create a Web service for you. For example, in the “Creating a Simple COM+ Test Application” section of the chapter, you’ll create a client application that calls a Web service that accesses a COM+ 1.5 application. When you create the Web reference to that Web service, the Visual Studio .NET IDE automatically builds a Reference.CS file for you. Contained within this file is a MathFunctionsService class definition that derives from the System.Web.Services .Protocols.SoapHttpClientProtocol class. Look in the \Chapter 11\C#\COMPlusTest\ Web References\main or \Chapter 11\VB\COMPlusTest\Web References\main folder of the source code located on the Sybex Web site for a detailed view of this class.

The fact that Visual Studio .NET performs all of this work for you is nice—it’s convenient, reduces development time, and can reduce errors. However, you need to consider just what type of code Visual Studio .NET generates for you. Most people won’t experience problems with the code, but you should at least look at it since this code is part of your application. For example, even the release version of your code will contain the System.Diagnostics .DebuggerStepThroughAttribute attribute for the MathFunctionsService class. When developing native code, most developers remove all debugging features from the release version. Not only does this step enhance performance, but it also makes it more difficult for the user to reverse engineer the code—a prerequisite for learning about any security holes in your code. To make matters worse, the Microsoft documentation is especially terse for this attribute—it’s hard to know why it’s included at all. Experimentation shows that you do need the DebuggerStepThroughAttribute attribute to ensure you can set a breakpoint within the proxy.

Tip

It’s important to consider some of the hidden security threats that can occur when working with Web services. For example, Microsoft Knowledge Base article 322866 (http://support.microsoft.com/default.aspx?scid=kb;[LN];322886) presents an interesting security issue. In this case, the developer might see a particular error message if the Web service lacks access to the \Temp folder. On the face of things, it would seem like a small problem that’s easily resolved. However, you have to wonder why a Web service would require access to your drive and what other areas the Web service can access. The Microsoft documentation doesn’t list this particular requirement anywhere, nor does it tell you about the security implications of providing access to this part of the system. The point is that you must monitor the activity of your Web service applications to ensure they remain within their designated areas and don’t begin looking in other areas of your system.

Let’s say that you really don’t want to keep this debugging feature in place when you release your product. Nothing says that you must use the Visual Studio .NET IDE method of providing a reference to your Web service. You can just as easily generate the proxy manually or you can use the WSDL utility to generate the class and modify it as needed. To generate the proxy class manually, open a command prompt and type WSDL -out:MathProxy.CS http://Main/MathFunctionsMethod/COMPlusComp.MathFunctions.soap?WSDL. You’ll need to substitute the URL for your server. The file WSDL outputs looks remarkably similar to the file generated by a Web reference. The only difference is that you can modify the source code as needed to meet security needs. Of course, the IDE doesn’t update anything automatically using this technique. When you change the component, you also need to generate this file again or add the changes manually.

Note

WSDL assumes that you use C#. If you use another language that WSDL supports, you need to specify it as part of the command line syntax. For example, Visual Basic users will need to type WSDL -out:MathProxy.VB -language:VB http://Main/MathFunctionsMethod/COMPlusComp.MathFunctions.soap?WSDL at the command prompt to get a Visual Basic version of the proxy. Again, you’ll need to substitute the URL for your server as part of the input.

The client code for this example is precisely the same as the client code shown in Listing 11.7. (You’ll find the complete source code for this example in the \Chapter 11\C#\COMPlusTest2 and \Chapter 11\VB\COMPlusComp2 folders of the source code located on the Sybex Web site.) The only difference is that you don’t need to add a reference to the proxy with the using statement because you created the proxy yourself. However, the most important difference is that you can edit the proxy code as needed to meet specific security requirements.

To see the effect of removing the DebuggerStepThroughAttribute attribute, try this experiment. Comment the entry out, as shown here,

using System.Web.Services; // Comment this attribute to improve performance and // reduce security problems. //[System.Diagnostics.DebuggerStepThroughAttribute()] [System.ComponentModel.DesignerCategoryAttribute(“code”)]

compile the application, and run it. You’ll notice that the code is smaller, uses a few less resources, and runs slightly faster.

You can try a number of other changes too. For example, WSDL assumes that you’ll run your Web service on port 80 of the Web server. You can choose other ports in the interest of security. All you need to do is change the constructor shown here.

public MathFunctionsService() { // Change this URL to use other ports. this.Url =    “http://main:80/MathFunctionsMethod/COMPlusComp.MathFunctions.soap”; }

One of the more interesting security problems with the generated proxy is that it doesn’t include any permissions checks. You don’t know that the caller has permission to make the request. For example, you can add the UrlIdentityPermission attribute to the code to verify the caller has permission to make the required proxy call. Proxies also make a good place to include custom permissions and to verify the caller is in a specific role.

Using a manually generated proxy also lets you decide how the user will call the Web service. Microsoft assumes that you want to include both synchronous and asynchronous access techniques—using a custom proxy lets you make all access synchronous or asynchronous as needed. The automatically generated proxy also includes every public method the Web service exposes. You might create a custom proxy that only exposes the methods you want the client to see. Some methods might only exist for in-house use. In general, reducing access to just the features a client needs improves security.

It’s important to remember that your proxy derives from the SoapHttpClientProtocol class. This class also includes a Credentials property you can use in the same way other classes in the book use this feature. Look at Listing 11.7 and you’ll notice that the client uses the MathFunctionsService.Credentials property that’s included automatically with your proxy. However, you can also override the default property and provide custom handling in your proxy (and call the base class to perform the default handling later).

Working with DiscoveryClientProtocol Class Security

Discovering services is important—it’s the first step in using a Web service you need for your application. However, like other Web service discussions so far, you need to consider who’s using the Web service, how they use it, and where they access it. In short, you need to provide some form of security. The technique for discovering the Web service varies, but in this section, you’ll learn the manual process that relies on the DiscoveryClientProtocol class. The Visual Studio .NET IDE also provides means for accessing the Web service using the IDE (the “Creating a Simple COM+ Test Application” section of the chapter discusses the automated method).

Previous chapters have discussed the issue of using attributes versus inline code for checking permissions. Web services are definitely one case where using attributes can become a problem. Consider the simple Web service shown in Listing 11.1.

Listing 11.1 A Web Service Using Security Attributes

namespace MathComp {    public class MathFunctions : System.Web.Services.WebService    {       public MathFunctions()       {          // Perform default action.          InitializeComponent();       }       [WebMethod,        ZoneIdentityPermission(SecurityAction.LinkDemand,           Zone=SecurityZone.Intranet)]       public Int32 DoAdd(Int32 Value1, Int32 Value2)       {          return Value1 + Value2;       }       ... Other Web Methods ...    } }

Notice that this Web service uses the ZoneIdentityPermission attribute to ensure the caller comes from the SecurityZone.Intranet zone. However, the attribute doesn’t work as expected in this case. Figure 11.1 shows the WSDL for this component—notice it doesn’t include a single method.

Figure 11.1: Attributes don’t work very well for Web service security needs.

If you attempt to use this version of the component for Web services, no one will access them. The use of the security attribute appears to keep everyone, even local users, from accessing the Web service. However, the new version in Listing 11.2 does work as anticipated and accomplishes the same task. You’ll find this example in the \Chapter 11\C#\MathComp and \Chapter 11\VB\MathComp folders of the source code located on the Sybex Web site.

Listing 11.2 A Web Service Using Imperative Security

namespace MathComp {    public class MathFunctions : System.Web.Services.WebService    {       public MathFunctions()       {          // Perform default action.          InitializeComponent();       }       [WebMethod]       public Int32 DoAdd(Int32 Value1, Int32 Value2)       {          // Validate the user has permission.          ZoneIdentityPermission  ZIP;          ZIP = new ZoneIdentityPermission(SecurityZone.Intranet);          ZIP.Demand();          // Return the requested value.          return Value1 + Value2;       }       ... Other Web Methods ...    } }

Using this technique permits the discovery phase to proceed as normal, yet doesn’t allow access to the Web service unless the caller has the correct rights. Figure 11.2 shows the output from this version of the component.

Figure 11.2: Use imperative security as needed to address Web service requirements.

Now that the Web service is working and more secure, let’s look at the client making the request using the DiscoveryClientProtocol class. First, you need to understand that using this class is the beginning of the journey, not the end. You receive the same information you receive when viewing the WSDL directly with a Web browser. The difference is that you can now manipulate the data with ease. Second, you’ll actually work with a document that contains the WSDL in the form of collections. This book won’t show you all the ins and outs of working with the collections because it focuses on security, but the information you can retrieve is substantial. Listing 11.3 shows the client portion of this example. You’ll find this example in the \Chapter 11\C#\MathCompTest and \Chapter 11\VB\MathCompTest folders of the source code located on the Sybex Web site.

Listing 11.3 Using the DiscoveryClientProtocol Class

private void btnTest_Click(object sender, System.EventArgs e) {    DiscoveryClientProtocol DCP;     // Web service discovery protocol.    NetworkCredential       NetCred; // Credential for current user.    CredentialCache         Cache;   // Cached credentials.    DiscoveryDocument       Doc;     // Results of the query.    StringBuilder           Output;  // Contains the discovery data.    ContractReference       ConRef;  // The Web service contract.    // Create the credentials.    NetCred = new NetworkCredential(txtName.Text, txtPassword.Text);    Cache = new CredentialCache();    Cache.Add(new Uri(txtURL.Text), "Basic", NetCred);    Cache.Add(new Uri(txtURL.Text), "Digest", NetCred);    Cache.Add(new Uri(txtURL.Text), "NTLM", NetCred);    Cache.Add(new Uri(txtURL.Text), "Kerberos", NetCred);    // Initialize the discovery protocol.    DCP = new DiscoveryClientProtocol();    DCP.Credentials = Cache;    // Make the query.    Doc = DCP.DiscoverAny(txtURL.Text);    ConRef = new ContractReference();    foreach (Object Temp in Doc.References)       ConRef = (ContractReference)Temp;    // Build an output string.    Output = new StringBuilder();    // Get the Bindings.    Output.Append("Bindings:\r\n");    foreach (System.Web.Services.Description.Binding Bind in       ConRef.Contract.Bindings)    {       Output.Append("\r\n");       Output.Append(Bind.Name);    }    // Get the Messages.    Output.Append("\r\n\r\nMessages:\r\n");    foreach (System.Web.Services.Description.Message Msg in       ConRef.Contract.Messages)    {       Output.Append("\r\n");       Output.Append(Msg.Name);    }    // Display the results.    txtOutput.Text = Output.ToString(); }

One of the essentials for this example is that you must build a CredentialCache object specifically for the Web service. Don’t build a CredentialCache object for the application Web site or the example won’t work. For example, the URL for my Web site is http:// winserver/0140/Chapter11/CSharp/MathComp/MathComp.asmx?WSDL. Notice that I’ve included the WSDL in my URL—you’ll need to include it as well. Each NetworkCredential includes a username and password as a minimum. You can also include a domain when required. Notice that the CredentialCache object is not only specific to the WSDL URL, but it also contains one entry for each type of authentication to ensure the program will make a connection. You can probably reduce it to one or two authentication methods for a local application because you’ll know how the administrator set the Web server up.

Using the DiscoveryClientProtocol object is relatively easy. The code creates a new instance of the object, adds the CredentialCache object, and then uses the DCP.DiscoverAny() method to obtain the data. The resulting DiscoveryDocument object contains all of the information you normally see in your browser and all of the hidden headers. At this point, you could lose the connection with the server and the application would still work because all of the data appears within the DiscoveryDocument object. View this object with the debugger and you’ll immediately see it several levels down in the hierarchy.

The problem is that you can’t access any of this information directly—it’s all contained in collections. The code shows how to retrieve a few pieces of information, such as the bindings used to create the connection. The Message objects describe the various SOAP messages you can create (and therefore the methods the Web service exposes for use). The final step is to output the information to a textbox on screen so you can see the data.