Re: [WEB SECURITY] websecurity Digest, Vol 35, Issue 9
Hey gautam,
Will you be kind enough to elaboarte some stpes or the tool available in
Appscan to scan WS. Do you have any guide handy with you?
Thanks
Biswa
On Thu, Nov 21, 2013 at 10:29 AM,
websecurity-request@lists.webappsec.orgwrote:
Send websecurity mailing list submissions to
websecurity@lists.webappsec.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
or, via email, send a message with subject or body 'help' to
websecurity-request@lists.webappsec.org
You can reach the person managing the list at
websecurity-owner@lists.webappsec.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of websecurity digest..."
Today's Topics:
1. Re: Web Service Security (Gautam)
Message: 1
Date: Thu, 21 Nov 2013 13:43:42 +1100
From: Gautam gautam.edu@gmail.com
To: Mario Robles whitehatcr@gmail.com,
brett.knuth@healthdirect.org.au
Cc: websecurity websecurity@lists.webappsec.org
Subject: Re: [WEB SECURITY] Web Service Security
Message-ID:
<
CAJC+O-RTh020JB3X0otz8W36jKAisqVqtz-od_4V-_ycV8KHdA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
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@hush.com<javascript:_e({},
'cvml', 'pawel.krawczyk@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? (
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@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
Hi Biswa,
I don’t have access to AppScan anymore so cannot give you step-by-step details.
In basic how AppScan worked was every time you configure a application and want to scan, you give it some basic steps and traverse the application as a normal user.
Internally what appscan does is it spawns a proxy and let these requests pass though it, while this is happening it records the user clicks.
Once the traverse is complete it uses this to perform injection on the boxes you traversed or the controls on the form.
We tried to exploit this working by spawning the traverse window, however instead of me clicking any links (which is not really possible in a WS testing environment) i used SoapUI to pass the traffic through this temporary proxy.
AppScan was happy to see this traffic and learn it and later it used this to perform the scan.
I am not sure if anything has changed to the scanner from the last time i used (1 year back). if Ory Segal is part of this mailing list he can give you some more tips.
Never knew anyone needed this, so never documented it.
Hope this helps.
Thanks,
Gautam
On 21 Nov 2013, at 8:08 pm, Biswa Bhusan biswabhusan.biswal@gmail.com wrote:
Hey gautam,
Will you be kind enough to elaboarte some stpes or the tool available in Appscan to scan WS. Do you have any guide handy with you?
Thanks
Biswa
On Thu, Nov 21, 2013 at 10:29 AM, websecurity-request@lists.webappsec.org wrote:
Send websecurity mailing list submissions to
websecurity@lists.webappsec.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
or, via email, send a message with subject or body 'help' to
websecurity-request@lists.webappsec.org
You can reach the person managing the list at
websecurity-owner@lists.webappsec.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of websecurity digest..."
Today's Topics:
1. Re: Web Service Security (Gautam)
Message: 1
Date: Thu, 21 Nov 2013 13:43:42 +1100
From: Gautam gautam.edu@gmail.com
To: Mario Robles whitehatcr@gmail.com,
brett.knuth@healthdirect.org.au
Cc: websecurity websecurity@lists.webappsec.org
Subject: Re: [WEB SECURITY] Web Service Security
Message-ID:
CAJC+O-RTh020JB3X0otz8W36jKAisqVqtz-od_4V-_ycV8KHdA@mail.gmail.com
Content-Type: text/plain; charset="windows-1252"
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@hush.com<javascript:_e({}, 'cvml', 'pawel.krawczyk@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@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