Hack proof your Web services
Web service router and IP blocking
The first additional technique involves using a Web service router and IP Blocking. As discussed in the first installment of this article, a primary concern for Web service developers is the security risk of making sensitive functionality available externally. This is, after all, the purpose of Web services, to be able to openly share and consume functionality between companies or individuals. This open sharing, however, creates greater security risks than are typical with standard Web sites—since most Web sites hide their functionality behind a user interface.
There are multiple ways a hacker can gain unauthorized access to data stored on a Web server. Hackers can imitate a legitimate user or IP address; or they can gain access through open ports on the server or any of a myriad of other attacks. This is why most companies hide employee computers behind a firewall: It makes it much more difficult for hackers to access the computers and steal data.
Denying access to hackers is the goal behind employing a Web router and IP blocking. In this scenario, there are two Web servers used to access the Web service. The first server sits outside the firewall and acts as a router. The second server is positioned inside the firewall and contains the actual Web service code. When an authorized client makes a call to the Web service, they call the router Web service on the server outside the firewall, passing in a parameter indicating which actual Web service they want to call. The router examines the parameter to determine where to route the request. Next, the router calls the Web service and awaits a response. When a response is received, the router passes the response back to the client (see Figure A).
Using a Web service router with IP blocking
This flexible scenario allows access to any number of Web services through a single router. A single-router Web service can route requests to any number of methods on any number of internal servers. Furthermore, since Web services are interoperable across operating systems, the internal services can be written in any language on any platform, regardless of the language or platform of the router Web service.
To complete the security, the servers inside the firewall are secured to only accept requests from the known IP of the server that contains the router Web service. This places the actual code inside the firewall, protecting it from a number of common attacks. It is much more difficult to access open ports or execute remote commands against a machine inside a firewall.
While this technique improves the overall security of your Web service functionality, it offers no additional protection against IP spoofing or other false authentication schemes. If a hacker can fool the router Web service, they can still gain access to actual Web services.
Parameter obfuscation
Since using a Web service router and IP blocking cannot protect a service from unauthorized use of the router Web service, which in turn, gives the attacker indirect access to the real Web service, you need to employ additional techniques to protect the router Web service. One of the concerns raised by Web services is that unauthorized users can easily determine the specific method and parameter names and types needed to access a function. This information is readily available in the WSDL file . Some products, like Visual Studio .NET , automatically create sample pages to allow interested users to type the parameters into a standard HTML form.
All of this makes it much easier for a would-be hacker to access your Web service and try to make calls to it, attempting to use random parameter values. For instance, if the hacker sees a method called RefundCreditCardCharge that accepts two parameters, CardNumber and Amount, it would be simple for the hacker to create his own call, passing in his own credit card number and a large dollar amount.
Of course, a Web service such as this is going to have other security measures in place, such as those discussed in the previous series on Web service security. However, if a hacker can overcome those security measures, there is nothing to stop him from refunding thousands of dollars to his own credit card.
One solution involves the use of parameter obfuscation to hide the details of the Web service call from the hacker (see Figure B). In this example, we could obfuscate the call by combining the two required parameters into a single, hard-to-duplicate parameter. This single parameter may be a simple XML string or a complex, user-defined combination of the necessary parameters.
Using a Web service router with IP blocking
The benefit of using parameter obfuscation is that the hacker sees a Web service called RefundCreditCardCharge with a single parameter called Data. The hacker has no way of knowing how the Data parameter should be structured, so it is much more difficult for her to initiate valid Web service calls. In turn, the Web service’s first action is to verify the structure of the Data parameter and return an error if it is incorrectly structured.
There is an additional benefit when parameter obfuscation is used with a Web service router. This setup allows the router to accept just two parameters, one parameter that identifies the destination method and another parameter containing the data for that Web service. It no longer matters how many methods are called from the router, or the number or types of parameters each of those methods require.
Parameter and result encryption
In the previous section, we discussed obfuscating parameters to deter hackers from executing Web service functionality using random parameter values. This solution works well in the scenario in which the hacker is looking directly at the service. It would not, however, offer additional security in instances where the hacker is intercepting calls made to the service.
If hackers can intercept a Web service call, they have access to the method name and details about all the parameters. Even if multiple parameters were obfuscated into a single, XML-based parameter, a hacker could easily determine the structure of the single parameter and mimic it in his own, unauthorized calls to the Web service.
Therefore, the next logical technique is to encrypt the parameters on the client before sending them to the server. This technique is easy to implement and works well in situations in which the Web service developer has some control or influence over the client. In the stockbroker example from the first article of this series, the brokerage site calls the stock purchase Web service. We could easily design this solution so the brokerage service uses custom code designed to encrypt the parameters sent to the Web service. Next, the Web service would decrypt the parameters before completing the request.
In this scenario, the Web service developer has control over how the client calls the Web service, so the developer can be the only one who knows the encryption key. There is no need to use a public key infrastructure since the same entity owns both sides of the encrypted communication. This makes the encryption much more difficult to break.
It also makes sense to encrypt the Web service response if it contains sensitive information. For instance, our fictional stock purchase service returns an object containing sensitive customer information such as a Social Security number. We need to encrypt the result to protect that information in the event the response is intercepted.
Multiple techniques yield ironclad security
I’ve examined several techniques designed to protect Web services from hackers and other unauthorized use. Web services that utilize any sensitive data or functionality should at least include SSL as a minimum form of security. While the other techniques may be overkill for typical Web services, they can be invaluable for extremely sensitive Web services such as banking and stock purchasing applications. For the highest level of security, all of these techniques can be combined, adding layers of difficulty. Clients that send encrypted, obfuscated parameters to a router Web service using SSL encryption, leave hackers out in the cold.