[WEB SECURITY] Web Service Security
gautam.edu at gmail.com
Wed Nov 20 21:43:42 EST 2013
What I have done In the past was use the IBM appscan as a proxy for the
soapui when they do the normal functional testing of the WS. In this step
appscan is learning the normal behaviour so I don't have to send a traffic
Once the learning is done you can then use appacan to scan.
This way I got some more results than before.
Hope this helps.
On Thursday, November 21, 2013, Mario Robles wrote:
> I've found that chaining SoapUI with burp suite as it's proxy helps a lot
> during WS testing
> IBM Appscan have a tool for testing WS as well
> Fully subscribe to Brett’s comment.
> Web services are very sensitive to a specific standard and implementation.
> One family is SOAP, which is multilayer protocol so even a simple service
> looks very complex. This is why there are no “point-and-click” SOAP
> security scanners - each scanner is actually a client for specific service
> and needs to be implemented from scratch. If you have WSDL, it’s quite
> easy. You can code it in Java, .NET, Python or SoapUI. One of the
> commercial scanners also has a built-in SOAP client, similar to SoapUI (I
> don’t remember which - IBM AppScan or HP WebInspect).
> At the end of the day you actually get a fuzzer and what you’re looking
> for are all kind of standard issues - unhandled exceptions, error messages
> etc. The good side is that SOAP programmes rarely sanitise their error
> messages in a fully justified belief 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
> AngularJS) and just pulling data from the server over AJAX or REST. 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.
> On 20 Nov 2013, at 21:56, Brett Knuth <brett.knuth at healthdirect.org.au>
> For what it’s worth ……
> We always take a risk based approach and map the possible threats to the
> web app depending on its specific components
> Build an attack tree or a threat table XLS, an example below
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity