Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

webservice security - hacked ?

 
Rama Raghavan
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mark O'Neill
Author
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic