Hackers will always look for the most vulnerable victims; those that require the least amount of effort to attack. When most networks built up their perimeter defense, hackers began to target Web applications. Now, with the advent of application-layer firewalls,
Let's review how Web services function, why hackers have started to prey on them and what organizations can do to mitigate this threat.
How Web services function
Web services allow other Internet-connected programs to interact with them by making certain functionalities accessible to other applications. They can range from a complex customer relationship management (CRM) system to a simple stock quote feed. They are built using a collection of protocols and standards such as XML, XML Schema, WSDL (Web Services Description Language) and SOAP (Simple Object Access Protocol), many of which are still evolving, and as with most new technologies, security issues are often overlooked in the early stages of adoption.
Web services vulnerabilities
Web services face a lot of the same vulnerabilities that Web applications do, such as SQL injection and session theft, but unlike traditional Web page interfaces, Web service programs are far more open, often connecting to core enterprise applications and data. This significantly increases their risk profile and makes them a very attractive target. Web services are usually deployed over HTTP to allow cross-network communication without having to reconfigure firewalls. This could be problematic for networks that use older firewalls, since older firewalls cannot analyze Web service traffic that travels via HTTP.
Web services threat protection
To mitigate Web services threats, enterprises that run Web services should deploy application-level firewalls that can examine XML-based messages. There are some firewalls on the market today that can enforce XML structural rules and validate schema, perform XML virus-checking and protect against XML denial-of-service attacks (XDoS); if available, use them. Additionally, your developers should also be educated on the additional XML-related attack vectors that Web services are vulnerable to, mainly:
- XML identity threats, updated versions of the traditional identity threats, such as authentication attacks and eavesdropping.
- Content-borne threats that use actual XML payloads to distribute XML viruses, SQL statements, Unix commands, etc.; and
- Operational attacks, including XML-level denial-of-service attacks and XML bombs.
Here are some additional rules organizations can use to reduce potential Web services risks:
- At a bare minimum, use PKI (public key infrastructure) authentication for machine-to-machine communications and SSL for communication security.
- Develop an ongoing list of resources that will provide you with information about current security problems and software updates relevant to your system and application software, since new infrastructure components are prone to vulnerabilities and must be continuously patched and updated.
- Upgrade your existing authentication and access control security policies to meet Web services specifications like Web Service Security (WS-Security), which addresses enhancements made to SOAP messaging to protect the message integrity, message confidentiality and message authentication.
- Keep abreast of the other new standards like XML Encryption, XML-Schema and XML-Digital Signature that aim to secure Web services traffic. Incorporate these standards into your security policy where appropriate.
- Finally, find and use a comprehensive guide on how to build secure Web services and Web applications and use it when developing your services. These guides are available from the Open Web Application Security Project through their Web site, OWASP.org.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.
This was first published in October 2006