[WEB SECURITY] Web Service Security
infosecm at gmail.com
Fri Nov 22 15:56:51 EST 2013
Thank you for your cooperation.
Your reply comes from your experience , which make it valuable.
What I see here. Is that most issue or concerns is similar to web
applications security issues (SQL Injectin, XSS ... etc)
I don't have much experience with web service, so I thought it may has its
Anyway, your comments and testing method were useful, and it is helpful to
establish the start.
Thank you everybody.
On Thu, Nov 21, 2013 at 5:43 AM, Gautam <gautam.edu at gmail.com> wrote:
> 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
>> El 20/11/2013, a las 05:26 p.m., Pawel Krawczyk <pawel.krawczyk at hush.com>
>> 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
>> 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
> The Web Security Mailing List
> WebSecurity RSS Feed
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> websecurity at lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity