As service-oriented architecture (SOA) is getting popularity, there’s growing interest in security testing of these services, but the tools available aren’t as advanced as those for “standard” web applications. Web services are very sensitive to a specific standard and implementation. One family is SOAP, which is multilayer, universal and scalable — so no wonder it tends to make even every simple service (hello world) look very complex.
This is why there are no “point-and-click” SOAP security scanners — each scanner is actually a client for specific service that needs to be implemented. If you have the service’s WSDL most of the complexity will be handled by either the SOAP testing tool (SoapUI, IBM AppScan also has SOAP client) or the SOAP programming framework of your choice (Java, .NET, Python).
What you eventuall get is a fuzzer and what you’re looking during security testing areall kind of standard issues — unhandled exceptions, error messages etc. The good side is that SOAP programmers rarely sanitise their error messages in a fully justified assumption that no normal human will look at these responses :)
It’s more challenging if the service uses advanced features such as digital signature or encryption, because as far as I’ve seen this domain can be not fully standardised. If you get there, you’ll practically need to reimplement the service’s client. And you might find out that there’s no good library for that in your favourite programming language, or there’s no library apart from one delivered by a vendor. Welcome to the murky world of proprietary business protocols… For Java there’s a book that helped me a lot with understanding the SOAP world - “Building web services with Java”.
A separate class of applications using web services are client-facing apps with most of the presentation logic implemented in JavaScript (e.g. AngularJS) and just pulling data from the server over AJAX from an API implemented in any of the popular web frameworks (e.g. Spring).
I like them because it’s easy to draw a trust boundary, the HTTP communications are easy to read and the APIs are also rather simple and clear to understand. Most of the manual testing tools such as BurpSuite will handle them pretty well.
Typical issues you’ll find in headless web services alone will be related to SQL, broken authentication and access controls. In case of modern AJAX apps, you’ll actually need to look at two sides: one is the web service, the other is the presentation layer. DOM-based XSS is prevalent here, but if you properly tested the API, you can be pretty confident that you’ll not get a data breach as all data goes through the API. Which is also a wonderful situation from secure coding perspective - e.g. in Spring (Java) the API definitions can be stored in single place, which makes code review and possible fixes much easier.
Additional references: