I think an attack vector that is often under-analyze is the web service.  There’s no user interface, so what’s the real danger? Cross-Site Scripting (which accounts for about 53% of all application vulnerabilities) is completely useless since there is no HTML response.  And how would one even use this tool without a user interface?

Well, obviously these services can be exploited and broken, and since it’s part of your organization’s infrastructure, it needs to be tested as thoroughly as any other application.  So how do we go about doing that?  There’s a tool called SOAPUI that creates an interface for you to send requests and receive responses.  It’s a great application, but it notorious in my department for giving us problems.  That’s a small price to pay for having all of these web services secured.  I would take a few moments to download the application and find a good basic tutorial on how to use it, as I’m going to focus more on how we can exploit these services.

Since these are SOAP requests, guess what we’re going to inject? SOAP injections! Here are some steps you can take to effectively test your web services:

• Submit a rouge close tag (for example, </test>) in each parameter.  If no error is occurring, your request is probably being sanitized in some way.
• If you do get an error, submit both an open and close tag (for example, <test></test>).  If this causes the error to disappear, the application might be vulnerable.
• Sometimes data that is inserted into an XML-formatted message can be read back from its XML form and returned to the user.  See whether any XML content you submit is returned in its identical form or if it’s normalized in any way.  Try submitting the following:
  • Test</test>
  • Test<test></test>

One may be returned as the other, or it may be returned without the tags.  Now you can be confident that your input is being inserted into an XML-               based message.

• Try inserting an open-comment (<!–) into one parameter and a close-comment (–!>) into another.  This may cause a change in the application’s logic and give you a different error message.  Always try different combinations of parameters.

Try these steps for each parameter.  Of course, you shouldn’t limit yourself to just testing for SOAP injections. SQL injections and other application errors are still relevant with these types of services.  All applications, even ones as simple as web services are critical to the integrity of your organization’s security.