Web Services Security Threats | Web Services Security

We’ve seen the positive side of Web Services security: the industry cooperation on new specifications and frameworks. Now let’s investigate the negative side. The new specifications that implement the principles of security for Web Services are useless if the user is required to “play by the rules.” A sophisticated authorization system using SAML and WS-Security is useless if the Web Service on which it runs can be disabled by a CodeRed attack. (CodeRed is a worm program that attacks IIS Web servers.)

Some of these “new threats” are, in fact, old threats, such as buffer overflow and attempts to exploit other programming errors, but the avenue of attack—SOAP—is new.

Firewalls have traditionally addressed vulnerabilities at the lower layers of the OSI stack. Firewall functionality has progressively moved up the OSI stack to reach the application layer. However, they are not yet “SOAP-intelligent.”

The following section examines these aspects of Web Services security.

Web Application Security

Application layer security existed long before SOAP. Application layer security for Web servers involves securing both the Web server itself and Web applications that use the Web server as their platform. A Web application is a CGI-based application with which the user interacts using a Web browser. Attacks on Web applications initially focused on attacking the platform itself, exploiting security holes in the Web server. These frequently took the form of buffer overflow attacks. Like the “ping of death” attack we saw at the network layer in Chapter 2, buffer overflow attacks on a Web server presented more data than the Web server expected. This data would be written to memory, and could find its way into the execution stream. This allows arbitrary commands to be executed on the server.

It is difficult and time-consuming to produce a buffer overflow attack, but once produced, the attack can be packaged into a scriptable tool that so-called “script kiddies” can use. Script kiddies use existing techniques and programs or scripts to search for and exploit weaknesses in computers on the Internet. The derogatory nature of the term refers to the fact that the use of such scripts or widely known techniques does not require any deep knowledge of computer security.

Gradually, buffer overflow attacks on HTTP implementations were addressed in patches to Web servers. At that stage, attacks began to exploit the extra features bundled with certain Web servers, features often installed whether users wanted them or not. These extra features included indexing engines and example scripts. After these holes were patched, it became more difficult for hackers to construct attacks on Web server software. This is when application layer hacking attacks progressed to attacking Web applications, rather than the platforms on which the Web applications run. These are not across-the-board attacks that can be packaged and used against thousands of Web servers by script kiddies. These attacks are specific to individual Web applications. However, they can be put into categories, including the following:

SQL attacks Inserting SQL statements into Web forms in order to force a database to return inappropriate data, or to produce an error that reveals database access information. For Web Services, this category of attack translates to manipulating data in a SOAP message to include SQL statements that will be interpreted by a back-end database.
Directory traversal attacks Attempts to bypass hyperlinks by attempting to directly access resources. For example:
- If a URL is http://www.example.com/documents/sales.htm, what happens if http://www.example.com/documents/ is requested?
- Does a directory called /test/ exist?
For Web Services, this category of attack translates to attempting to detect other SOAP services which are not explicitly offered.
URL string attacks Manipulating CGI name/value pairs in the URL string; for example, changing “maxResults=10” to “maxResults=1000” to return more information from a database. For Web Services, this translates to circumventing the rules on SOAP parameters (for example, if a search SOAP service takes an integer between 1 and 10 as a SOAP parameter, what if the number 1000 is submitted?).

Many of these attacks can be avoided by implementing careful programming practices and by cleaning up resources that are not required on the Web server. However, it is often the case that no matter how much care is taken; vulnerabilities can slip through the net.

Tip

In order to guard against the possibility of attacks on application vulnerabilities, consider the use of an XML firewall or XML proxy to filter SOAP requests before they reach your application.

When bound to HTTP, SOAP itself can be seen as a Web application, albeit a more standardized and formalized application than what has gone before. It is likely that initial SOAP implementations will be vulnerable to attacks based on invalid data such as buffer overflow attacks or attacks based on SOAP routing that attempt to create SOAP “worms.” This vulnerability is not necessarily due to carelessness but, rather, due to the fact that all security bases cannot be covered in initial versions of any software. The lesson from the history of Web server attacks is that once the platform is secured, the playing field shifts to the applications implemented on that platform. These attacks are potentially more dangerous than in the case of CGI applications; because of the nature of the business processes implemented using SOAP.

The Role of Firewalls for Web Services

“SOAP bypasses firewalls.” This phrase is frequently heard. Let’s examine what it means. The first question to ask is: What is a firewall? The answer is that different categories of firewalls apply to different layers of the OSI stack.

Packet-Filtering Firewalls

The lowest layer at which a firewall works is layer 3. At this level, the firewall checks if the information packets are from a trusted source and is not concerned with the content of the packets. These are called “packet-filtering firewalls” and are usually part of a router. IP packets are compared to a set of criteria and dropped or forwarded accordingly. These criteria can be source and destination IP address, source and destination port number, the protocol used, and the format of the IP packet.

The “ping of death” that we encountered in the previous chapter applies at the network layer and is protected by packet-filtering firewalls. Much of this functionality is now built into operating systems and routers.

Circuit-Level Firewalls

At layer 4, firewalls filter traffic based on more sophisticated criteria. TCP layer firewalls are known as “circuit-level firewalls.” These firewalls monitor TCP handshaking to determine a session’s legitimacy. Information about the protected network they are protecting is hidden, because packets appear to originate from the firewall and not from an address inside the protected network. These firewalls do not filter individual packets; rather, filtering is based on the rules of the TCP session, including who initiated the session and at what time.

Circuit-level firewalls prevent “session hijacking”—sending an IP packed that is intended to appear as if it belongs to a trusted session. It also hides an internal network from an attacker who wishes to scan it for vulnerabilities.

Application-Level Gateways

Application-level gateways filter packets at the application layer. They are aware of what traffic meant for specific applications should look like. For example, it knows the difference between Web traffic and telnet traffic, even though both use TCP/IP. Application-specific commands and user activity can be logged. These firewalls are relatively processor-intensive.

An application-level gateway will know that if it is protecting an e-mail POP server, the command “USER” is allowed, and takes one parameter (that is, the username). Anything else is not allowed. For example, traffic that looks like telnet traffic directed to the POP server will be blocked.

Stateful-Inspection Firewalls

Stateful-inspection firewalls operate at multiple levels and include much of the functionality of packet-filtering firewalls, circuit-level firewalls, and application-level gateways. These are complex and powerful, but tend to be difficult to configure. When not properly configured, they may contain security holes.

Application Layer Firewalls

Many firewalls have been configured to only allow Web (HTTP, SSL) and e-mail (POP, SMTP) traffic to pass. Other TCP/IP ports, and other protocols, are routinely blocked. It has become standard practice to “tunnel” other applications through the Web ports (80 for HTTP, 443 for SSL), effectively disguised as normal Web traffic. This is generally not done for malicious reasons, but rather for pragmatic reasons, because all other ports are blocked. In particular, SOAP is very frequently bound to HTTP. It provides a standardized means for applications to communicate over the Web ports. One of the lessons of computer industry history is that standards drive usage and SOAP promises to enable the explosive growth of application communication over the Web ports.

When a firewall examines a SOAP request received over HTTP, it might conclude that this is valid HTTP traffic and let it pass. Firewalls tend to be all or nothing when it comes to SOAP. A SOAP-level firewall should be able to:

Identify whether the incoming SOAP request is targeted at a Web Service that is intended to be available.
Identify whether the content of the SOAP message is valid. This is analogous to what happens at the network layer, where IP packet contents are examined. However, at the application layer it requires knowledge of what data the Web Service expects.

Content-Filtering Security at the Application Layer

Web Services present a new avenue of attack into the enterprise. Even so, some of the tactics are familiar: feeding unexpected data to an application in order to confuse it, or disable it. In Chapter 2 we saw how the “ping of death” was an attack that operated at the network level to provide unexpected data in an Internet Protocol (IP) packet. Web Services present details of their interface in WSDL files, which effectively say, “Here are the details of the data that I expect.” This invites a hacker to send it inappropriate data in order to see what happens.

A WSDL file may contain the following line:

<xsd:element name="tickerSymbol" type="string"/>

This indicates that one of the parameters expected by the Web Service is a string, called “tickerSymbol.” The options for a speculative attack on this Web Service would include sending it a number instead of a string, or sending it a very large string designed to overload the Web Service. It is important, therefore, that “sanity checks” are performed on incoming data directed to Web Services. This may take the form of checking SOAP parameters against an XML Schema. However, XML Schema validation is processor-intensive. In addition, certain portions of a SOAP message may be volatile, meaning that they change while in transit between the SOAP requester and the Web Service. Volatile portions of a SOAP message include the header, which may contain routing information that changes as the message is routed. Therefore, it is more appropriate to use XPath to narrow down the data validation to nonvolatile portions

of the SOAP message.

Another aspect of content filtering is ensuring that only valid Web Services are called. Firewalls must be able to distinguish SOAP requests from invalid requests. A valid request and an invalid request may differ only on the basis of the SOAP method called. The following code listing shows a valid SOAP request to a method called “GetTime” that takes a time zone as a parameter:

<SOAP-ENV:Envelope  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header></SOAP-ENV:Header> <SOAP-ENV:Body> <SOAPAPP:GetTime xmlns:SOAPAPP="http://tempuri.org/message/"> <TimeZone>GMT</TimeZone> </SOAPAPP:GetTime> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

The following code listing shows a SOAP request that targets another Web Service method, called “ResetComputer”:

<SOAP-ENV:Envelope  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <SOAPAPP:ResetComputer xmlns:SOAPAPP="http://tempuri.org/message/"> </SOAPAPP:ResetComputer> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

The challenge for firewalls is how to allow the first SOAP message, targeting a valid method of a Web Service, and to block the second one. There are analogies with firewall functionality at lower layers of the OSI stack. Filtering on the targeted SOAP method is only the first step, however.

Filtering on the data that is provided to a Web Service is more complicated. The details of each Web Service are specific. Consider a Web Service that takes a ZIP code as a parameter. The valid input is a five-character string. If the Web Service receives 5,000 characters as input, this may indicate that an attacker is testing for vulnerability to a buffer overflow attack. In order to block this sort of attack, a firewall must be aware of what type of data is valid for the Web Service.

The Next Steps for Firewalls

Application layer security began by ensuring that connecting entities played by the rules for applications that ran over TCP/IP; then, they progressed to patching holes in Web servers; and now it has moved to blocking attacks on Web applications. A SOAP implementation bound to HTTP may be seen as a Web application itself, and therefore the next step is to prevent SOAP implementations from attack. After protecting the SOAP implementation, the final step is to protect Web Services that use that SOAP implementation.

The challenge is to ensure that the firewall rules are in sync with the Web Services themselves—and it seems obvious that UDDI and WSDL should be used for this purpose. UDDI, after all, is used to return a list of deployed services. A dynamic updating firewall could query this list using a UDDI query such as we encountered in Chapter 1, and use this to ensure that only legal traffic passes through.

The next challenge is to ensure that only permitted traffic travels out of the network to third-party Web Services. A number of organizations are investigating the establishment of two-way Web Services gateways that act as “choke points” for SOAP traffic. This ensures that only valid SOAP traffic comes into the enterprise, and only valid SOAP traffic leaves the enterprise.

This is the natural evolution of firewall functionality, which began at the network layer and has been “climbing the ladder” of the OSI stack ever since.

Hint: When choosing a firewall product, check if the vendor supports SOAP filtering. A firewall should be capable of blocking SOAP messages based on target (endpoint) and based on the payload of the SOAP message, validated against an XML Schema.

This is the end of Part I. We have seen what Web Services are, what the high-level principles of security are, and how security is applied to Web Services. Part II looks at the implementation technologies in-depth.