Web services threats require specialized application security

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,

    Requires Free Membership to View

hackers are moving on to Web services.

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 security
Web services next battlefront for hackers 

Web services security a challenging endeavor 

New chapter and verse on Ajax security 

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 tip originally appeared on SearchSecurity.com.

This was first published in October 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.