Securing Web Services in the Cloud

Almost every SaaS (software as a service) is based on REST or XML Web services. In this post, I’d like to provide a brief introduction to some typical threats and security countermeasures to protect Web services;

Malicious Attack on the message

The beauty of HTTP Web Services is that traffic flows through port 80 and port 443 and it uses a human-readable format (XML or JSON). This is also the key vulnerability.

A typical IT / system administration approach that relies on protecting Web service providers with a firewall/IPS setup is not very effective. We will explain why.

Firewalls do a good job of port monitoring and recognizing brute force malicious attack but are not good at being able to view the content of messages in order to detect and prevent more sophisticated security compromises.

While most firewalls can recognize SOAP as well-formed HTTP traffic they cannot inspect the actual content of the SOAP message or JSON data. Web Services interfaces are much more complex than Web site interfaces which exchange HTML pages and forms.

Web service interfaces are like software APIs and expose database functionality. In addition, an attacker has more information available to them. The message is often self-describing and clearly shows the data elements.

A Web service provider is a juicy, self-describing target.

Replay Attack

Similar to Denial of Service, replay attacks involve copying valid messages and repeatedly sending them to a service. Similar techniques for detecting and handling Denial of Service can be applied towards replay attacks.

In some ways, replay attacks are easier to detect with Web Services because payload information is more readily available. With the right tools, patterns can be detected more easily even if the same or similar payload is being sent across multiple mediums like HTTP, HTTPS, SMTP, etc.

Buffer Overflow

An attacker can send a parameter that is longer than the program can handle, causing the service to crash or for the system to execute undesired code supplied by the attacker.

A typical method of attack is to send an overly long request, for instance, a password with many more characters than expected. Similar to buffer overflow attacks; hackers often send malformed content to produce a similar effect.

Sending in strings such as quotes, open parentheses and wildcards can often confuse a Web Service interface.

Dictionary Attack

Dictionary attacks are common where a hacker may either manually or programmatically guess passwords to gain entry into the system. Administrators should ensure that passwords are difficult to guess and are changed often.

Intrusion Detection of attacks by malicious outsiders

Proactively securing all of the possible misuses of Web Services is almost impossible. Security policies and strict access control management should help reduce the occurrence of intrusion.

An IPS will detect anomalous attack behavior and if monitored may help the security team mitigate the threat.

Extrusion detection of attacks by trusted insiders

Attackers are usually thought to be outside of the organization. However, most security breaches occur from within the organization. With Web Services, more functionality is available to a more people.

Access to confidential information or embezzlement of funds is just some of the possible internal security breaches that can be performed by employees or former employees. Because employees are the most familiar with internal systems, detection can be made extremely difficult.

Unintentional compromises are also possible. If an interface is unsecured, an employee may accidentally access information that they are not intended to view. Since Firewalls are insufficient for data breach, we would require use of a DLP – Data loss prevention system such as Fidelis XPS or WebSense DLP.

Threat containment

Once a security breach is detected, being able to shut down systems and reject traffic from specific sources are important for handling a compromise. A DLP system provides real-time detection, forensics recording and the ability to drop traffic from specific IP source addresses in order to properly mitigate the threat.

Fred Williams
Great article on an interesting subject. I've been developing web services for a few years for my employer and I can only see more growth in this area. The reason is that separate of concerns dictate that UI layers can be swapped out but the backend systems won't change. So that the next whizbang technology that comes along doesn't force developers to rewrite the entire system. Just the 'view' into the data. More growth means the attack surface continues to expand.

A third form of web services could also be Messaging oriented middleware (MOM) that depend on message queues and a pub/sub workflow. Those message will also be human readable and subject to the same problems that you outline here.

W3C actually defines two standards that can assist in malicious attacks on the message: XML Security and WS-Security. XML Security gives you integrity (XML Signature), confidentiality (XML Encryption), key managements and authorization controls. Many tools support XML Security like Axis3 from Apache. So, if you are sending a request to a web service with customer information like so:

<?xml version=’1.0’ encoding=’UTF-8’ standalone=’yes’ ?>

John Q. Public

1234567
200.00
433-66-9999

You can see sensitive information in plain text. XML security will allow you to encrypt as much of the message as you need, for performance sake. (The encryption will defintely have performance impacts.)

<?xml version=’1.0’ encoding=’UTF-8’ standalone=’yes’ ?>

John Q. Public

A2354BC

WS-Security works by extending web service messages that allow for using XML Security withing SOAP messages.

These technologies by itself doesn't guarantee perfect security. It is recommended to use SSL/TLS to secure each endpoint in the web service architecture. The difference is that WS-Security uses end to end security rather than point to point. WS-Security is able to cross mulitple trust domains this way.

Extensive logging by the web service developers also go a long way in detecting misuses of your web service.Also be sure that server side validations are in place and input sanitations are extensively used.

1295543368

Fred Williams
Oh well, my XML tags were scrubbed out but you get the idea.

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.