File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes webservice security - hacked ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "webservice security - hacked ?" Watch "webservice security - hacked ?" New topic
Author

webservice security - hacked ?

Rama Raghavan
Ranch Hand

Joined: Aug 22, 2001
Posts: 116
1. What are the vulenrabilities with regards to using SOAP / web services ?
2. Are there additional risks of being hacked when using web services ?
Rama
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Rama Raghavan:
1. What are the vulenrabilities with regards to using SOAP / web services ?
2. Are there additional risks of being hacked when using web services ?

Well, as Web Services are basically about transferring XML messages over HTTP (mostly), there should be few new vulnerabilities when compared to plain HTTP requests.
However, there are some points to consider for the paranoid... The fact that Web Service interfaces are publicized with UDDI makes it easy for a black-hat to figure out where to send requests and how should the request look like, etc. These "dangers" are real only if the designer gets sloppy with security.
What's more of a problem is the propagation of identity and information in a workflow where several enterprises take part in fulfilling a request. On the other hand, those problems are not due to Web Services per se.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Mark O'Neill
Author
Greenhorn

Joined: Feb 26, 2003
Posts: 5
Originally posted by Lasse Koskela:

Well, as Web Services are basically about transferring XML messages over HTTP (mostly), there should be few new vulnerabilities when compared to plain HTTP requests.
However, there are some points to consider for the paranoid... The fact that Web Service interfaces are publicized with UDDI makes it easy for a black-hat to figure out where to send requests and how should the request look like, etc. These "dangers" are real only if the designer gets sloppy with security.
What's more of a problem is the propagation of identity and information in a workflow where several enterprises take part in fulfilling a request. On the other hand, those problems are not due to Web Services per se.

Initial Web Services rollouts are tending to be in partner-to-partner situations, rather than to the entire world. The phrase "Web Services" implies to some people "services deployed out to the entire Web", but this is the exception, not the rule, right now, and probably for the forseeable future. Rather, Web Services means "A services oriented architecture implemented using Web technologies such as XML". What it tends to mean in practical terms is "getting XML data from Company X to Company Y, safely and reliably - in a cheaper way than using a private EDI network". This is less of a "big idea" than things like global UDDI directories and ad-hoc business relationships, but it is more practical and actually solves existing problems, rather than making new ones.
So, I agree that the first real problem is managing the identity of access to services. i.e. ensuring that only trusted partners can access the Web Services. This involves processing SAML assertions embedded in SOAP messages sent from partners (indicating that the end-user has been authenticated in their security domain), as well as processing other types of security tokens which are embedded in SOAP messages using WS-Security [e.g. X.509 digital certificates].
In terms of new attacks made possible by Web Services - ones I'm seeing are:
- Providing inappropriate data to a Web Service - e.g. malformed XML, very large messages, broken XML Signature, etc.
- Attacks against security services themselves. e.g. clogging attacks against processors of XML Encryption or XML Signature structures. For example: validating XML Signature data may include pulling down a resource based on a URI in the "resource" section of the XML Signature structure. If this resource is a 100MB file, the signature checker will grind to a halt. 100 concurrent similar messages and the whole system grinds to a halt.

- Replay attacks [i.e. intercepting and sending the same SOAP message again. It's important to realise that if your system will authorize a certain SOAP message, will it authorize the exact same message if it's received again - if so, it's potentially vulnerable to a replay attack]
In protecting against these attacks - there is an architectural choice to make. Do you secure the traffic flow [i.e. put an XML Gateway/Firewall in place as a proxy], or do you secure the endpoints themselves [i.e. build security into your code, or use an XML security tool which has agents that hook into your XML platform].
-Mark
Mark O'Neill
CTO, Vordel
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: webservice security - hacked ?