Web Service Security
Hi !,
I'm looking for resources help me to identify web service security issues,
and how to fix them.
I just found OWASP Web Service Security Cheat Sheet talking about this
matter.
I know that web service security issues is very similar to web
applications, but there is always something you unaware of.
OWASP Web Service Security Cheat Sheet:
https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet
Regards,
Info Sec,
That is a hard question to answer. There are different types of Web
Services, each type has multiple implimenations, and each implimetnation
allows for different configuration options.
The security testing is different depending on type, the implimentation,
and the configuration of each web service.
For a high level overview of Web Service Security, I have found the
following document helpful:
http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
Some tools that you can use to test web services are:
Any web proxy (Burp Suite, Fiddler, ZAP, etc) - For all web services
SoapUI - for SOAP based web services where you have access to the WSDL
Oyedata - For RESTful web services that use OData
Good luck. Hopefully someone else on the list can provide more
information.
-Seth
On Tue, Nov 19, 2013 at 6:51 AM, Info Sec infosecm@gmail.com wrote:
Hi !,
I'm looking for resources help me to identify web service security issues,
and how to fix them.
I just found OWASP Web Service Security Cheat Sheet talking about this
matter.
I know that web service security issues is very similar to web
applications, but there is always something you unaware of.
OWASP Web Service Security Cheat Sheet:
https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet
Regards,
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
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
SQL Injection
Web logs/application logs
HTTP request (GET/POST request, source IP, UserAgent, referrer, date/time)
Once documented and risk assessed we then vulnerability and pen test, remediating the most critical risk assessed
Brett Knuth
Security Manager
P. xxxxxxxxxxx M. 0402 891 533 F. 02 9283 9180
MAIL. Suite 3, Level 19, 133 Castlereagh St Sydney NSW 2000
E. brett.knuth@healthdirect.org.aumailto:brett.knuth@healthdirect.org.au
[Health Direct Australia]
Please consider the environment before printing this email
Important notice: This message and any attachments are confidential and may contain legally privileged or copyright material. Any confidentiality or privilege is not intended to be waived or lost by mistaken delivery to you. If you are not the intended recipient, any unauthorised use is strictly prohibited. If you have received this email in error, please notify us and destroy the original transmission and any copies. It is your responsibility to check any attachments for viruses and defects before opening them or sending them on.
From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Seth Art
Sent: Thursday, 21 November 2013 6:44 AM
To: Info Sec
Cc: websecurity@lists.webappsec.org
Subject: Re: [WEB SECURITY] Web Service Security
Info Sec,
That is a hard question to answer. There are different types of Web Services, each type has multiple implimenations, and each implimetnation allows for different configuration options.
The security testing is different depending on type, the implimentation, and the configuration of each web service.
For a high level overview of Web Service Security, I have found the following document helpful: http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
Some tools that you can use to test web services are:
Any web proxy (Burp Suite, Fiddler, ZAP, etc) - For all web services
SoapUI - for SOAP based web services where you have access to the WSDL
Oyedata - For RESTful web services that use OData
Good luck. Hopefully someone else on the list can provide more information.
-Seth
On Tue, Nov 19, 2013 at 6:51 AM, Info Sec <infosecm@gmail.commailto:infosecm@gmail.com> wrote:
Hi !,
I'm looking for resources help me to identify web service security issues, and how to fix them.
I just found OWASP Web Service Security Cheat Sheet talking about this matter.
I know that web service security issues is very similar to web applications, but there is always something you unaware of.
OWASP Web Service Security Cheat Sheet:
https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet
Regards,
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@lists.webappsec.orgmailto:websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.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” (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
SQL Injection
Web logs/application logs
HTTP request (GET/POST request, source IP, UserAgent, referrer, date/time)
Once documented and risk assessed we then vulnerability and pen test, remediating the most critical risk assessed
Brett Knuth
Security Manager
P. xxxxxxxxxxx M. 0402 891 533 F. 02 9283 9180
MAIL. Suite 3, Level 19, 133 Castlereagh St Sydney NSW 2000
E. brett.knuth@healthdirect.org.au
<image002.jpg>
Please consider the environment before printing this email
Important notice: This message and any attachments are confidential and may contain legally privileged or copyright material. Any confidentiality or privilege is not intended to be waived or lost by mistaken delivery to you. If you are not the intended recipient, any unauthorised use is strictly prohibited. If you have received this email in error, please notify us and destroy the original transmission and any copies. It is your responsibility to check any attachments for viruses and defects before opening them or sending them on.
From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Seth Art
Sent: Thursday, 21 November 2013 6:44 AM
To: Info Sec
Cc: websecurity@lists.webappsec.org
Subject: Re: [WEB SECURITY] Web Service Security
Info Sec,
That is a hard question to answer. There are different types of Web Services, each type has multiple implimenations, and each implimetnation allows for different configuration options.
The security testing is different depending on type, the implimentation, and the configuration of each web service.
For a high level overview of Web Service Security, I have found the following document helpful: http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
Some tools that you can use to test web services are:
Any web proxy (Burp Suite, Fiddler, ZAP, etc) - For all web services
SoapUI - for SOAP based web services where you have access to the WSDL
Oyedata - For RESTful web services that use OData
Good luck. Hopefully someone else on the list can provide more information.
-Seth
On Tue, Nov 19, 2013 at 6:51 AM, Info Sec infosecm@gmail.com wrote:
Hi !,
I'm looking for resources help me to identify web service security issues, and how to fix them.
I just found OWASP Web Service Security Cheat Sheet talking about this matter.
I know that web service security issues is very similar to web applications, but there is always something you unaware of.
OWASP Web Service Security Cheat Sheet:
https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet
Regards,
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
--
Pawel Krawczyk
pawel.krawczyk@hush.com +44 7462 166716
CISSP, OWASP
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
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
SQL Injection
Web logs/application logs
HTTP request (GET/POST request, source IP, UserAgent, referrer, date/time)
Once documented and risk assessed we then vulnerability and pen test,
remediating the most critical risk assessed
Brett Knuth
Security Manager
P. xxxxxxxxxxx M. 0402 891 533 F. 02 9283 9180
MAIL. Suite 3, Level 19, 133 Castlereagh St Sydney NSW 2000
*E. *brett.knuth@healthdirect.org.au
<image002.jpg>
Please consider the environment before printing this email
Important notice: This message and any attachments are confidential and may
contain legally privileged or copyright material. Any confidentiality or
privilege is not intended to be waived or lost by mistaken delivery to you.
If you are not the intended recipient, any unauthorised use is strictly
prohibited. If you have received this email in error, please notify us and
destroy the original transmission and any copies. It is your responsibility
to check any attachments for viruses and defects before opening them or
sending them on.
From: websecurity
[mailto:websecurity-bounces@lists.webappsec.orgwebsecurity-bounces@lists.webappsec.org
] *On Behalf Of *Seth Art
Sent: Thursday, 21 November 2013 6:44 AM
To: Info Sec
Cc: websecurity@lists.webappsec.org
Subject: Re: [WEB SECURITY] Web Service Security
Info Sec,
That is a hard question to answer. There are different types of Web
Services, each type has multiple implimenations, and each implimetnation
allows for different configuration options.
The security testing is different depending on type, the implimentation,
and the configuration of each web service.
For a high level overview of Web Service Security, I have found the
following document helpful:
http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
Some tools that you can use to test web services are:
Any web proxy (Burp Suite, Fiddler, ZAP, etc) - For all web services
SoapUI - for SOAP based web services where you have access to the WSDL
Oyedata - For RESTful web services that use OData
Good luck. Hopefully someone else on the list can provide more
information.
-Seth
On Tue, Nov 19, 2013 at 6:51 AM, Info Sec infosecm@gmail.com wrote:
Hi !,
I'm looking for resources help me to identify web service security issues,
and how to fix them.
I just found OWASP Web Service Security Cheat Sheet talking about this
matter.
I know that web service security issues is very similar to web
applications, but there is always something you unaware of.
OWASP Web Service Security Cheat Sheet:
https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet
Regards,
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
--
Pawel Krawczyk
pawel.krawczyk@hush.com +44 7462 166716
CISSP, OWASP
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
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
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@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@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
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Infosec,
As mentioned by others on this thread, there is a lot of contextual information that goes into the attack surface of a web service. Identifying the appropriate communication scheme (ala REST/SOAP/JSON/AMF etc.) stuff is just the tip.
Injection attacks like SQL Injection depend on the back end components your target service uses. Client-side attacks like cross-site scripting are possible however the risk they present is dependent on how the application is hosted and who uses it.
Attacks are contextual, performing a proper threat modeling session with the product owners and decision makers is key to any application assessment including web services.
Cheers,
D
On Friday, November 22, 2013 12:59 PM, Info Sec infosecm@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@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@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
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
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@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@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@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
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@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
On 19. Nov 2013, at 12:51 PM, Info Sec infosecm@gmail.com wrote:
Hi !,
I'm looking for resources help me to identify web service security issues, and how to fix them.
I just found OWASP Web Service Security Cheat Sheet talking about this matter.
I know that web service security issues is very similar to web applications, but there is always something you unaware of.
OWASP Web Service Security Cheat Sheet:
https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet
Regards,
Dear all,
You might want to read that paper
http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2012/07/11/camera-ready.pdf
and you also might want to try the tool "ws attacker":
http://sourceforge.net/projects/ws-attacker/
Cheers,
Sebastian