Keeping hackers out of your Web services
Published: 14 May 2002 13:09 BST
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.
| Figure A |
![]() |
| SSL encrypts communications using a public key infrastructure. |














