[WEB SECURITY] Web Service Security

GAUTAM P gautam.edu at gmail.com
Sat Nov 23 01:55:03 EST 2013


Hi InfoSec,

I concur to all that has been said here by some of the senior folks. One point that I would like to mention is that if you are still in the design phases of the WS then its right time to consider “Secure by Design” . You will hear a lot about this, however in a fast paced development cycle most of the team skip this and don’t do it correct

From my experience most of my team by now understand the issues of data sanitisation, however one point that we run into is authentication and Authorisation controls for the WS.  You will need to see who are the users of the WS and if they all are trusted and similar questions.

WS-Security was giving me some comfort on how i could handle this, i am still not done much of REST based so let me know how you are handling this if you are using REST based services. Most of the org’s are going REST way these days.

Thanks,

____________________________
Thanks,
Gautam

On 23 Nov 2013, at 7:56 am, Info Sec <infosecm at gmail.com> wrote:

> Hi all,
> 
> 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 own flaws.
> 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. 
> 
> Gautam
> 
> 
> 
> 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> 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
> 
> 
> -- 
> 
> Regards,
> 
> Gautam
> 
> 
> _______________________________________________
> The Web Security Mailing List
> 
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
> 
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> 
> WASC on Twitter
> http://twitter.com/wascupdates
> 
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
> 
> 

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


More information about the websecurity mailing list