Service-oriented architecture (SOA) has progressed from an industry buzz word to a preferred design principle for business systems igniting a system design shift that gave birth to the powerful tool known as Web services.
In case you don’t already know, Web services are modular chunks of functionality that organizations publish and allow trading partners to access. Many of today’s popular Web applications use Web services as the behind-the-scenes engine for their more complex functionality.
This raises the troubling question: How do we secure these new interfaces we are developing?
The Big Gun Threats
In order to secure something you need to first understand the threats to which it may be vulnerable. Web services have an interesting threat profile. They are standard pieces of functionality, typically written in .NET or Java, and often connect to file systems and databases like the programs we are accustomed to writing. As a result, Web services are not exempt from the major threats that we concern ourselves with when securing traditional software. Attack vectors like the buffer overflow, SQL injection and other parameter tampering threats, also apply to Web services. However, Web services introduce a few more, including:
WSDL Scanning: A WSDL (Web services definition language) is used to describe the Web service to connecting parties. Our trading partners use these documents to discover what pieces of functionality are available to them and how to format their requests to the Web service. Care needs to be taken when creating and publishing these documents. Often the documents are automatically generated from the code and functionality not meant to be exposed to outside entities is included in our WSDL. This may allow an attacker unintended access functionality.
XPath Injection: XPath is a language for querying information from XML documents. Similar to SQL Injection, if user input is not properly sanitized, it is possible for a malicious user to influence the XPath query being run by the software to garner more information than he/she would normally have access to.
Recursive Payload: The communication sent back and forth via Web services is all XML based, giving the attacker a new avenue of attack. Knowing that the Web service will need to parse the XML message in order to process the request, an attacker can send a request which contains a large amount of nested opening tags, but never supply a closing tag. The Web service, when trying to parse this file, will often consume too many system resources or even crash as it needs to track open tags until the matching close tag occurs. This can cause a denial of service to the Web service.
Opening pieces of functionality to third parties is wrought with threats, both old and new. For this reason it is paramount that developers understand these threats and how to protect their applications from potential attack. The biggest roadblock to securing Web services is understanding that it is difficult to do so.
The three tenets of security are confidentiality, integrity and availability (CIA). In the world of Web services, availability is the most straightforward to achieve. Typical attacks against Web services availability would be based on bad data, which is determined to choke the application and cause it to crash. Developers need to define strict rules for their input to act as guidelines for validation. Any and all data is then validated against these rules prior to use by the system. This will help protect against availability attacks. Although protecting the availability of Web services is no simple task, it is much easier than protecting confidentiality and integrity.