[WEB SECURITY] Web Service Security

Gautam 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
for learning.

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
> Cheers,
> Mario
> El 20/11/2013, a las 05:26 p.m., Pawel Krawczyk <pawel.krawczyk at hush.com<javascript:_e({}, 'cvml', 'pawel.krawczyk at hush.com');>>
> escribió:
> 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” (
> http://amzn.to/1auRwqA)
> 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 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>
> wrote:
>  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
>  *Injection*



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20131121/22b35f03/attachment-0003.html>

More information about the websecurity mailing list