Walk Down the Right Paths
When moving from a controlled client to a web services approach one faces the possibility that functions may be called out of sequence. Think about a simple every-day process like making a cup of coffee and imagine if we had software functions for the key activities:
Executed in this order, we get a decent cup of coffee. The process has some tolerance for failure too in that the order of pour_coffee() and pour_cream() aren’t particularly important but the fact that they both precede stir() is.
While existing software might have forced users to do these steps in order, slapping a web services front-en onto the application means careless users or attackers might be able to execute them out of order because they may be able to access these functions directly—with unspecified results.
If you carry this analogy to financial transactions, there may be some disastrous implications of allowing activities to be done out of sequence.
Context
One of the biggest mistakes when rolling out web services is failing to look at how the system will be deployed. A common pitfall is to assume your application, transactions, and data will be protected by existing enterprise defenses.
An interesting property of web services transactions is data often flies by such defenses without any real inspection. Given that transactions happen as globs of XML, network defenses lack the contextual information to determine if a specific message is hostile or contains data that can potentially cause the application to fail.
Another common snag is failing to test the security of both the client and the server. One must always protect the server from malicious data being sent from a user but it is equally important to make sure client applications are robust and can handle responses to web services requests that may be generated by an attacker impersonating the server.
Web services continue to change the way applications interact. The approach offers a solution to the problem of having applications communicate without needing to consider their implementation.
Like any new technology, it brings benefit as well as risk to the IT environment.
As more information flows through HTTP, we need to consider not just the code that’s written but how that shift in communications conflicts with or negates network defenses that may already be in place.
As with any new technology trend it is important to remember the law of attacker economics: The more a technology gets used, the more it will be attacked. If built with security in mind, though, SOA has the ability to reduce risk by shielding an application instead of simply exposing it to would-be attackers.
Dr. Herbert Thompson is chief security strategist at Security Innovation.