Web Services are Prone to Attacks

Web Services are a new set of standards with relatively new vendor implementations. There are many reasons why Web Services are prone to attack.
First of all, Web Services are a new type of interface or API to existing and new applications. Because Web Services are standardized, there is little “security through obscurity.” There is very little proprietary about Web Services which greatly ease the access and consistency of access of Web Services. In addition, Web Services are human readable and self-describing. SOAP messages provide information and structure for each message. WSDL documents provide significant information about each Web Service, including where the service is, how to access it, what kind of information to send to it and what type of information you should expect to receive back. In some cases, it may reveal the tool that generates or hosts the Web Service. This provides significant information to a potential intruder to inappropriately access the service.
One might incorrectly assume that because Web Services are mostly intended for programmatic access that there is some security through obscurity or that the average end-user cannot access them. This is entirely incorrect. Microsoft Excel is an example of a tool everyone has that enables any user to easily communicate with a Web Service. Many user-friendly GUI-based tools can be downloaded to find, bind, analyze and exchange information with a Web Service. These tools enable an attacker, without any programming experience to easily play around and hack into a Web Service interface. Some of these tools can even SSL to a Web Service.

Web Services traffic also tunnels through port 80 and port 443. Existing tools such as network firewalls provide little protection against Web Services traffic. They may provide some simple filtering capabilities but cannot provide consistent protection across a diverse set of Web Services. IDS systems can also catch some specific attacks and viruses but does not provide specific protections against XML-based attacks. Application firewalls typically provide protection only against HTML and browser-based attacks and not against the XML message stream.
SSL is part of an overall solution recommended by many companies and analysts but does not alone have the visibility in the message to provide the proper security to mitigate risks. Web Services requires granularity on encryption. For example, encrypting sensitive information while exposing routing information in clear-text. This is the reason why the XML Encryption, XML Signature and WS-Security standards were invented and ratified. Viruses and other malicious XML can just as easily be transported encrypted as in clear-text. In fact, it can be harder to detect a compromised SSL connection because it is passing encrypted attacks.
SSL is a good technology for protecting pipes between machines. SSL should be used in conjunction with other security mechanisms to provide transport-level security for Web Services but it is neither purpose-built nor adequate for most security for Web Services. SSL and IP filtering operate on the machine level, providing only a clumsy level granularity for securing Web Services. It does not provide application or user-level authentication or authorization capabilities nor provides encryption and non-repudiation at the element level. Below are some of the reasons why SSL is not recommended as the only solution for securing Web Services.

First of all, SSL can be expensive to provision. Managing the environment and procuring the technology for every single possible requestor and Web Service combination is a definite challenge and a significant cost. Some Web Services may have hundreds and thousands of different requestors. If you were using, for example, mutual SSL, managing the keys across a diverse set of participants would be costly from a management standpoint and represent a potential security risk.
It is possible that SSL can be compromised but the likelihood is dependent on the key sizes being used. What is more common is not automatically checking revocation lists (CRL’s) whereby the termination points do not check for expired and revoked keys. Many Web Services are also stateless. Creating and tearing down SSL connections for every single message can cause performance problems. In addition, encrypting the entire message can be less efficient than encrypting just specific portions of the message that truly need to be encrypted.
Another important deficiency is that SSL only protects the transport between two computers or devices. If any of the endpoints or intermediaries (such as routers) are compromised, then transport security provides no protection against attacks sent from a compromised machine. Compromised endpoints (often caused by a host-level
break-in) can occur for a number of reasons. A disgruntled employee, a recently fired worker or someone who simply wants to take advantage of the system can easily use their knowledge to compromise a machine and perform malicious actions that are very difficult to track with no other checks and balances in place. With only SSL or IP filtering protection, a compromised machine can be used to attack any Web Service that that machine has access to.

Because Web Services are often used (or planned to be used) in external environments such as B2B communication or across firewall communication, there is a reliance on external parties and their security capabilities. If a partner’s machine is compromised, then SSL provides a convenient pipe for an outside hacker to attack your systems. Relying on the security mechanisms of an entity outside your control is a major security risk and is obviously not a recommended practice.

Not all endpoints will necessarily support SSL. Given the types of endpoints such as desktop applications like Microsoft Excel or even wireless applications like phones, many of these are more likely to support XML Encryption, XML Signature and more granular forms of authentication for communication than SSL.

Diverse Applications Means Diverse Attacks

Any type of application can be behind the Web Service interface. They range from packaged applications such as SAP and Peoplesoft to internally developed applications like J2EE and .NET developed programs to desktop applications. Legacy applications like mainframes can also be exposed via Web Services. These applications obviously carry their own security vulnerabilities which are likely to be even more exposed via Web Services interfaces. In addition, they all approach security in different ways. This presents a significant security challenge to protect these services consistently.
Diverse Applications Means Diverse Attacks
■ New type of interface
• Web Services is human readable and self-describing
• SOAP, WSDL can reveal tools that generated it
■ Applications behind service may be unprepared
• Tunnels through HTTP and port 80.
• Legacy apps like mainframes, desktop apps, etc. are ill prepared
• Lack of consistency in back end applications
• Many different types of applications each with their own vulnerabilities
■ Existing security mechanisms don’t secure these attacks
• App firewall filtering protects only HTML traffic
• IDS systems catch specific app attacks
• Network firewalls catch only network attacks
■ Similar results from developer mistakes or bad programming

Because Web Services are easy to access and relatively easy to compromise, the likelihood of successful attack is quite high.