Defending Your XML Web Service against Hackers, Part I

  • Article

 

Matt Powell
Microsoft Corporation

September 5, 2001

Introduction

One of the biggest concerns we hear from developers when we talk about the potential of XML Web Services is the fear of vulnerabilities that might allow malicious users to attack their services. The bad news is that attacks can result in such atrocities as limiting the availability of your service, private data being compromised, or in the worse case, losing control of your machines to these malicious users. The good news is that there are real protections available to you that can limit the risks involved from these attacks. We are going to take a look at what kind of attacks are out there, and what you can do to protect yourself in the areas of deployment, design and development. This first column on the subject will focus on deployment issues you should consider; in our next column, we will look at design and development issues that you need to be aware of when developing your XML Web Services.

Types of Attacks

The first step to figuring out what the risks are, and what we can do to avoid them, is to understand the types of attacks that might target our services. Once we know the sorts of issues we are vulnerable to, we can mitigate those risks by taking appropriate actions.

Attacks fall under three general categories:

  • Spoofing
  • Taking advantage of bugs
  • Denial of Service

Spoofing

One of the most common attacks against a system that requires authentication is for a hacker to figure out a user’s authentication credentials, log on as that user, and access that user’s information. This is bad enough, but it can pose even more of a risk if the compromised credentials belong to a system administrator or some other higher privileged user. In such a case, the attack might not only compromise a single user’s data, but could potentially compromise the data of all users.

There are various approaches a hacker might use to determine a user’s password. For example: trying words that might be meaningful to the user, such as the user's name, their pet’s name, or their birthday. A more persistent hacker may even try every word in the dictionary (a dictionary attack). Other ways of getting at credential information include: sniffing the network packets and reading the information from the data being sent; by DNS spoofing, inserting a malicious machine as an intermediary between a client and the server; posing as a system administrator and requesting the user give their credentials for trouble-shooting purposes; or by recording a logon handshake with a server and replaying the sequence in order to attempt to get authenticated.

Much of the risk of spoofing can be mitigated by taking such measures as enforcing strong passwords, and by using secure authentication mechanisms.

Taking Advantage of Bugs

One of the key factors determining the vulnerability of a system to attack is the quality of the code running on that system. Bugs on the system can do more than simply cause a particular thread to throw an exception. Hackers can potentially use these vulnerabilities to execute their own code on the system, to access resources with elevated privileges, or to simply take advantage of resource leaks (based on the bug) that can potentially cause your system to slow down or become unavailable. One of the most famous of this sort of attack is the Code Red Worm virus, which took advantage of a bug in the Index Server ISAPI extension to execute code of its choosing on an infected system, and then went looking for other vulnerable machines.

Another common attack is to take advantage of bugs where assumptions are made on the validity of input data. For instance, consider an XML Web Service that expects a user name to be entered as a parameter. If you assume that the user name just contains an ASCII string, and so place it directly into your SQL query, you may expose your service to serious vulnerability. For instance, say you have a SQL query in your code that is built like this:

sqlQuery = “SELECT * FROM Users WHERE (Username=’” & UsernameInput & “’)

If the UsernameInput parameter happens to contain something like

Bob’) or not (Username=’0

then your service may return all records, and not just the one for a specific user.

Denial of Service

Denial of service attacks are not aimed at breaking into a site, or at changing its data; rather, they are designed to bring a site to its knees, so that it cannot service legitimate requests. The Code Red Worm virus not only infected machines and then looked for more machines to infect, it also caused the infected machines to send a large number of packets to the official White House Web site. Because thousands of machines were infected, the number of requests sent to the White House Web site was extremely high. By sending requests from a large number of machines, the Code Red Worm virus became what is considered a "distributed denial of service attack," which is extremely difficult to limit, since there are so many machines involved.

Denial of service requests may come in many forms, because there are so many levels at which bogus requests can be sent to attack your system. For instance your site may allow users to PING your IP address, which causes an ICMP message to be sent to your server and then returned. This is an effective means of troubleshooting connectivity problems. Nevertheless, if hundreds of machines send thousands of packets each to your server at the same time, you will probably find that your machine is so busy handling the PING requests that it can’t get the CPU time to handle other, normal requests.

A slightly higher level is a SYN attack, where a low-level network program is written to send what appears to be the first packet (a SYN packet) in a TCP connection handshake. This tends to be more damaging then a PING request, because unlike PING requests, which can be ignored if you want, as long as you have an application listening on a TCP port (like your Web server) you are vulnerable to expending resources whenever you get what appears to be valid connection requests.

On the high end of the spectrum, denial of service attacks can take the form of sending to your XML Web Service multiple, basically valid SOAP requests that cause database lookups to occur. Database lookups may take a long period of time. thus, if thousands of such requests are sent to your server every second, it can cause both the Web server that receives the request, and the database server on the backend, to become excessively busy. Again, this may cause your service to be unable to handle other requests in a timely manner.

If you have code with bugs on your machine, then denial of service attacks may be even easier. For example, if your production Web Service made the mistake of displaying a message box in the case of a particular type of error, a hacker could use this flaw to send a relatively small number of requests to your machine that cause the message box to be displayed. This can lock up all of the threads handling requests, thereby effectively making your service inaccessible to others.

Deployment Issues

Now that we have seen the different sorts of attacks, what can be done about these nasty assaults? The good news is, there is a lot you can do to protect yourself, and most protections are very straightforward. Let’s begin by looking at the sorts of protections you can enable simply by controlling how your Web servers and your back-end servers are configured.

There are a number of important safeguards you should take to insure that your Web servers are invulnerable to attack, including such obvious measures as making sure you have the latest security update. What follows is a list of the most important steps you can take to protect yourself. Many of these items are not specific to hosting Web services, but apply to any Web servers hosting content.

Install the Security Update

First, make sure that you have the latest update, so that you are not vulnerable to the Code Red Worm virus. The instructions for installing the update, including links for downloading the patch, can be found at Installing the patch that stops the Code Red worm.

The fix for the Code Red Worm virus and other fixes will eventually be in the next service pack for Microsoft® Windows® 2000 and are already addressed in Microsoft® Windows® XP.

Of course the bigger issue is how do you stay on top of other potential vulnerabilities, and protect yourself from future problems that might arise. For information on Microsoft product security issues, you can subscribe to the Microsoft Security Notification List. Subscribers are notified by e-mail of any new problems that come up. For directions on how to sign-up, check out the Product Security Notification page.

Limit Who Can Access Your Web Servers

If you are concerned about attacks, particularly if you have information on your XML Web Service that is private, then you should restrict access to your site to legitimate users only. This can be achieved in a number of ways, but here are a few that can keep attackers from accessing your XML Web Service.

  1. Authenticate users by using HTTP authentication; then limit the resources they have access to. Authentication is configured by: right-click on the Web site, virtual directory, or individual file in the Internet Services Manager; select the Properties option from the pop-up menu; go to the Directory Security tab and click the Edit button under Anonymous Access and Authentication Control.
  2. Restrict the IP addresses that can access your Web server. If you have a small list of legitimate users who can use your site, you may want to only allow their particular IP addresses to have access. You can also limit access to certain ranges of IP addresses, or deny access to an IP address or a range of IP addresses. You can even limit access based on domain names, but that requires potentially lengthy domain name lookups on the IP addresses that connect to your machine. IP address restrictions are modified by: go to the Directory Security tab mentioned in step 1, and clicking on the Edit button under IP address and domain name restrictions. Figure 1 shows the IP address and domain name restrictions dialog with access limited to three specific IP addresses.

Figure 1. Setting IP address restrictions for your Web site

  1. Require Secure Sockets Layer (SSL) connections with client certificates. This is probably the most secure way to authenticate users who access your site. SSL restrictions are also made from the Directory Security tab under Secure Communications.

Configure Your Router to Only Allow the Access You Require

Your router is your firewall; it can block the vast majority of illegitimate requests that can be sent to your machine. Most popular routers can restrict access to specific TCP ports, so you may want to only allow incoming requests on port 80, the default HTTP port. This restricts anyone on the outside of your firewall from trying to connect to any other services on your machine. Be careful about opening up ports for other services. It may be convenient to open up a port to allow you to connect to your Web servers with Terminal Services Client so you can do remote administration, but then anyone can try to connect to your machine with a terminal server connection. Even if a hacker does not know a valid user name and password, the hacker can still use up a lot of resources on your machine by establishing multiple sessions simultaneously that only display the logon screen.

Routers are also key tools in filtering out illegitimate packets that can use up resources on your machine. Obviously malformed packets should simply be thrown away—most routers will do this automatically—but many routers today also have the ability to detect things like TCP SYN packets that say they are sent from an IP address other than the one they came from. By enabling this kind of protection, you can avoid those SYN attacks mentioned earlier in relation to denial of service attacks.

Also keep in mind that firewall restrictions only impact traffic at the firewall. This may seem to state the obvious, but consider the situation where you purchase a T1 line from an Internet Service Provider (ISP), and you place a securely configured router on your end of the T1 line. If your ISP fails to enable the detection of invalid SYN requests on their routers, then their routers are vulnerable to SYN attacks, and can potentially deny service to the other side of your T1 line, effectively cutting off access to your site.

In complex environments where there may be numerous routers on either side of a specific connection, each router is a potentially vulnerable target for attack that can affect your ability to provide legitimate users with access to your site. To get a list of routers that your packets will go through to reach your server, use the TRACERT.EXE utility.

Configure TCP/IP Filtering to Limit Ports that Connections Are Accepted On

If you don’t have a router for your firewall, or if you are unable to administer your router for any reason, you can effectively make your own machine your firewall by limiting the sorts of incoming connections it will receive. In Windows 2000, click the Start button, select Settings, select Network and Dial-Up Connections, right-click the network card that is connected to the Internet, and select Properties. Select Internet Protocol (TCP/IP) and click the Properties button; click the Advanced button and go to the Options tab. Select TCP/IP filtering and click the Properties button. You will see a dialog box like that shown in Figure 2. Here you can restrict the ports that you will receive connections on. In the example shown in Figure 2, access is restricted such that only ports 80 and 443 for HTTP and HTTPS connections are allowed.

Figure 2. Configuring TCP/IP filtering

Remove Unneeded Services and Software

The more software running on your machine, the more likely you will be vulnerable to attack, particularly if you have services running as some sort of high privileged user. If your machine is dedicated to running your Web Service and your Web Service alone, then start disabling some of the other services on your machine. This includes the FTP service, the SMTP service, as well as Windows services such as Terminal Services Client.

The amount of software running or accessible through Internet Information Server should also be limited. Make sure that the only virtual sites and directories you have configured are ones you need. The Administration Web Site is probably the first thing that needs to be removed. The IISSamples virtual directory should be removed as well. Again, if you have a machine dedicated to running your Web Service, you should remove any other virtual directories.

Even on the virtual directories you do have installed, you have to be careful about what sort of software is available for requests to access. In Internet Services Manager, if you right-click a site or virtual directory, select Properties from the menu, choose the Virtual Directory tab, and click the Configuration button, you will see the App Mappings tab, which lists all extensions associated with different ISAPI extensions or CGI applications. If you are not using these extensions, remove them from the list. The index server extension for .IDQ files had a bug in it that was responsible for the Code Red Worm virus. If you make this change at the virtual site level, you won’t have to worry about making it for each virtual directory that is created.

Use the Microsoft Internet Information Server Security Checklist

Microsoft created a security checklist for Internet Information Server 4.0 that mentions all that I have mentioned here, as well as much more. Use this checklist to make sure you have at least considered all your options for security. Though you are probably not running Internet Information Server 4.0 (5.0 is the version that comes with Windows 2000), most of the steps still apply, and will continue to apply to future versions of Internet Information Server. The checklist can be found at Microsoft Internet Information Server 4.0 Security Checklist.

Conclusion

There are numerous measures—specifically with regard to how your machines and your network are configured—that you should take to protect your Web servers against attack. In our next column, we will continue looking at ways to protect your XML Web Services from attack by looking at issues developers and architects need to be aware of when creating their XML Web Services.

 

At Your Service

Matt Powell is a member of the MSDN Architectural Samples team, where he helped develop the groundbreaking SOAP Toolkit 1.0. Matt's other achievements include co-authoring Running Microsoft Internet Information Server from Microsoft Press, writing numerous magazine articles, and having a beautiful family to come home to every day.