It’s meant to bring a certain agnosticism to technology and standardize the transmission of data and information through XML and SOAP. Despite what web services and the resulting service-oriented architecture (SOA) delivers now and promises to deliver in the near future the technology still has a major hurdle to overcome: Security.
The security concerns that come bundled with SOA are similar to the threats that rose with the growth of the Internet. In fact, there are several security parallels to be drawn for systems between Internet connectivity and SOA.
Both allow more direct communication to potentially vulnerable code residing on the backend. Both were adopted faster than one could manage the risk: SOA in particular creates a level of connectivity that was never designed for by the makers of the legacy applications it often exposes.
Mainframe terminal application developers, for example, were most concerned with performance, accidental entries, and reliability because their users were trusted and hard-wired. Connectivity removes trust from the operating environment.
The SOA risks are often very individualized, taking different forms at every instance and in every company. The result is, in many cases, security landmines waiting to be triggered by the treading attacker.
If web services are implemented with security in mind though, they can fundamentally reduce risk through proper filtering and limiting the exposed surface of the application to the outside world.
Data Gone Wild
Most software security vulnerabilities come from assumptions about data not being enforced. As an example, consider an application that processes customer information, and one particular field, “Customer Surname,” that is assumed to be no longer than 20 characters.
The application typically receives this data from a client application that checks to make sure no more than 20 characters are passed to the server application. Now imagine putting a web services interface on that server application.
Data is transmitted as part of an XML document, with likely no constraint. If a client sends a request with more than 20 characters, the result could be a potentially exploitable application fault such as a buffer overflow.
This means when software is exposed through web services we need to take care that data is properly constrained. The ideal case is, of course, to validate data within the application but, for legacy systems, this filtering may not exist and no longer be a feasible option.
Beyond data being sent to the server, when a web service is created an implicit contract is forged between the provider and user application about the format and range of data exchanged.
Back-end server code may be changed which alters response data. A client may be built assuming it will receive a fixed-sized response. If the implementation changes, client applications may be at risk. When implementing web services then, it is critical to establish a set of data boundaries and those boundaries remain consistent even after plumbing changes of the underlying code.