COMMENTARY -- As an architect, the time I spend with customers is valuable in helping me define industry trends. What I'm hearing lately indicates the current focus within Web services is the existence of threats. Organizations have been asking how to defend against network attacks, and about preventative measures to ensure they don't happen in the first place.
Articles, whitepapers and vendor presentations addressing these threats are peppered with exotic terms like schema poisoning, parameter tampering, coercive and parsing, giving an almost comic-book glamour to the unique risks associated with Web services.
Affected terminology aside, these are issues that require attention. Where the Web provides an HTML-constrained view of an application program interface (API), Web services are more raw, machine-to-machine communications. The flexibility and platform-independence they provide in a loosely-coupled architecture is truly beneficial, but also opens the door to a plethora of concerns.
Web services expose higher-value transactions to attack, and therefore have a proportionately higher risk. Decoupling messages from the security measures "baked in" to applications, platforms and transport protocols brings risk. We need to be aware of the dangers with the Web services model, and be concerned about the risks associated with deploying them, even within the relatively benign shores of our internal networks.
Here are five things you need to know about Web services threats:
1. Individualized threats can command too much attention, at the expense of taking a broad perspective.
To put it simply, individual attacks are red herrings. The intent of any attack is to prevent normal operations (for example, denial of services in the Web world), or access legitimate operations for illegitimate purposes. The menagerie of XML-specific threats ultimately set out to accomplish one or both of these goals. The main difference is the mechanism used which seems to grow more convoluted over time. Really, most attacks fall into three broad categories which your architecture needs to address. They are:
- API attacks (including attachments, the biggest overlooked area) which attempt to crash your applications or directly exploit them for malicious purposes;
- Infrastructure attacks (including parser attacks, such as well-documented Web services provider weaknesses) which aim to deny access to services or paralyze your infrastructure;
- Transaction attacks (that is, message exchange pattern, not necessarily ACID transaction) which may insert bogus transactions or suppress legitimate ones.
New Web services standards and specifications appear even as older ones are being ratified. Vendors are quick to support not only standards, but also proprietary features that address their shortcomings. Customers are tapping into the potential of Web services, creating innovative new ways to integrate applications and build services. Deployments are evolving from purely internal to cross-entity and B2B. Change is constant, and only an adaptable security architecture can win this war.
2. Standards are important, but don't have all of the answers.
The OASIS Web Services Security (WSS) model provides a framework to implement message-based security that can defend against a number of well-known attacks. But it describes a means to secure messages; it doesn't necessarily tell you how to do it. Similarly, WS-I Basic Security Profile constrains and disambiguates OASIS WSS for the purposes of promoting interoperability, but it doesn't explicitly tell you how to make your messages secure.
The real problem is that securing messages, either using WSS or something as commonplace as SSL, is difficult and subject to error. Look at the conventional Web. As proponents of the REST architectural style sagely point out, the Web security model was pretty simple: associate access control with URLs, and wrap the whole thing in SSL if you need confidentiality and integrity.
This echoes the elegant simplicity of Unix file system security. Mapping non-file resources into this brings consistency, and consistency is the soul of good security. Nevertheless, look at how exploited the Web has become. If we had such trouble managing browser access, how are we to approach something as complex as Web services security, where we may need to parse XML simply to understand what policy to apply? It is critical to architect with a goal of managing this complexity.
3. Take advantage of the flexibility Web services should be giving you.
Web services are becoming the latest victim of the tendency to develop security on an application-by-application basis. This is the antithesis of loose coupling - the reason for adopting Web services and SOA in the first place - where a security model is baked into the code; it defeats the best attempts to compose future applications. There are now theoretical attacks against SHA secure hashes. What is your plan to deal with this? Open up applications and start re-coding your digital signatures?
Web services security needs to be drawn out of individual applications and managed centrally and declaratively. Only this method will create a cohesive security view of your service network.
Most Intrusion Detection System (IDS) flag a lot of false positives - it's one of the things keeping network administrators so busy, and why the Intrusion Prevention System (IPS) market hasn't been as wildly successful as IDS. Some network traffic, despite being perfectly legitimate, simply matches intrusion signatures that are necessarily broad.
Attack prevention sometime runs into the same issues at the application protocol layer. Consider: the naive approach to locating potentially dangerous SQL metacharacters is to run a regular expression across a blob of XML searching for hash signs (among other specific characters).Unfortunately, that also picks up the shorthand XPointers that are recommended as a means of reference in the WSS model. So a blanket approach just doesn't work.
4. Strive for flexibility in your security infrastructure as well.
What will work is a fine-grained policy enforced at a Policy Enforcement Point (PEP) for Web services, which applies threat protection customizable for every message. Maybe you don't want to scan XML for SELECTs if you know that an application has no underlying connection to a relational database. Maybe you want to search for SQL injection under all circumstances as a matter of corporate security policy. The point is that the rules need to be flexible, because there will always be cases where good judgment must prevail and exceptions will be made.
I wrote my first XML messaging application for a customer in 1998. It's still running today. It's not a SOAP application; it doesn't use XML-RPC; but it is mission critical to them and it will probably run pretty much unchanged for years, like any entrenched system.
These existing XML and SOAP legacy systems are a big concern because they predate so many of the security models we have built to protect modern Web services. It is critical that your Web services security architecture accommodates arbitrary XML, and not just contemporary SOAP.
5. Don't forget about files.
Messaging still isn't the primary application of XML in an organization - files are. Developers jumped on XML as a file format first, and a careful audit in any large IT department will find numerous applications that have XML preferences files, or do I/O using XML formats. These are where the creaky old parsers particularly susceptible to tricks reside - it's like conning the elderly. A security architecture must have a means to audit, sanitize and manage these files. They are your weakest link - ignore them at your peril.
There is no magic bullet for Web services threats, and thankfully, no magic is required to protect your organization either. The combination of some serious introspection, a few off-the-shelf tools, and ongoing vigilance will yield a solid security framework that not only prevents the threats you are reading about now, but the ones that have yet to be discovered.
The side benefit will not only be protection from threats but a robust security model that will gracefully extend to new deployments and future architectures.
Scott Morrison is the director, architecture and security at Layer 7 Technologies.
