Weeding out Web hackers
Before we delve into the security concerns unique to Web services, it is important to understand what type of hackers you are trying to keep out of your Web services. Although it is impossible to guess the motivations of potential Web service hackers, it is important to understand the different types of hackers that could be attacking your service. We are concerned with three primary types of hackers: the disruptor, the information thief, and the functionality thief.
The disruptor
The goal for this type of hacker is simply chaos. Disruptors will try to shut down your Web service, alter data on the Web server, and perform other malicious deeds simply for the satisfaction that they can be done. This type of hacking is annoying and can damage your business from a service availability standpoint, but its impact is usually minimized by diligent Web site monitoring and a good backup policy. The other types of potential Web service hackers can be much more damaging to your business and your company.
The information thief
The goal for an information thief is to gain unauthorized access to your company or customer information. This information can be used for many purposes ranging from credit card theft to corporate blackmail or espionage. Information thieves can be more dangerous to Web services than to standard Web sites, because many Web services are specifically designed to disseminate sensitive information. For example, if your company's Web service provides reports about your customers that include credit card information or addresses and phone numbers, a hacker can impersonate an authenticated user to steal this information and sell it to the highest bidder. Likewise, if your consulting firm provides reports about potential clients through a Web service, your competitors could hack the Web service to gain your list of leads for their own use. Although all Web sites are at risk for this type of hack, Web services are particularly vulnerable because you are publicly publishing a direct link to the information itself.
The functionality thief
This type of hacker is a new threat with the advent of Web services. Most standard Web sites do not directly expose their internal functionality to users. The core functionality of the site, whether it is purchasing stocks or transferring money between accounts, is usually protected behind a user interface and multiple security checks. With Web services, that same functionality must be exposed directly to the end user to consume with a single call. This makes hijacking your Web service functionality much easier because a hacker would only need to intercept a single call to the Web service to gain all the knowledge he or she needs to make his or her own calls to the function.
Imagine, for instance, that you provide a Web service that allows users to purchase stocks through a broker. The broker's Web site allows users to select the type and quantity of stock they want to purchase and then collects the funds for the purchase. The Web site then makes a single call to your stock purchase Web service, indicating the type and quantity of stock, as well as information about the user purchasing the stock. If a hacker can intercept that Web service call and replace the purchaser's information with his or her own, the Web service then sells the stock paid for by the legitimate user to the hacker. Or imagine if the hacker logs in to the broker's site and arranges a purchase for him or herself. Because he or she is initiating the transaction, he or she will know exactly when the Web service call will be made, making it easier to intercept. The hacker can then increase the number of shares that he or she has purchased. Now your Web service is assigning 1,000 shares of stock to the hacker when he or she only paid for 10.
The first layer of protection
The first level of protection for all Web sites and Web services is Secure
Sockets Layer (SSL). This is the current industry standard that is commonly used
to protect all credit card transactions on Web sites; it’s used by every major
Web browser on the market. SSL uses a Public Key Infrastructure (PKI) to secure
all communications between the client machine and the server. The PKI uses a
Certification Authority, such as VeriSign, to decide upon an encryption to be
used by both the client and server.
The first step in an SSL transaction is a client request for secure communications with the server. If the server is configured with a digital certificate, it will respond to the request with a copy of its certificate and the public portion of its encryption key (see Figure A). The client verifies the public key against the Certification Authority to ensure that it hasn't been tampered with. Once the public key is accepted, the client prepares its request and encrypts it using the public key received from the server. The encrypted message is then sent to the server, which decrypts the message using the private portion of the key stored on the server.
SSL encrypts communications using a public key infrastructure.
SSL provides secure communications with both minimal development time and transparent usage. Because SSL encrypts all communication on the client machine, hackers intercepting Web service calls will only be able to see the encrypted message, protecting the secrecy of your method names and parameter definitions.
Nevertheless, there are some potential pitfalls to consider before depending on SSL alone to protect your Web services. There is the cost associated with purchasing a digital certificate and service from a Certification Authority. This cost can be as high as $1,000, depending on the Certification Authority and encryption strength of the certificate purchased.
Furthermore, despite the cost, the strength of the certificate purchased does not necessarily determine the strength of the encryption used for each transaction. Most browsers support full 128-bit encryption. However, due to export laws, these same browsers must also provide a weaker, 40-bit encryption version. The number of bits used to encrypt the message determines the difficulty in breaking the encryption. Even if you purchase a128-bit certificate for your Web server, if a client browser (or other application) only supports 40-bit encryption, the messages will be automatically encrypted with the weaker protection.
Another concern is the ability of hackers to break the encryption. A hacker can easily obtain the public portion of your SSL key by simply accessing a secure Web service and analyzing the traffic passed between the client and server. With the public key, it is possible to determine the private key, which would allow the hacker to decrypt all traffic hitting your Web service. This is a difficult process and not easily available to every would-be high school hacker, but if your Web services offer great-enough rewards, such as money transfers or stock purchases, it is well within the realm of possibility.