Sneak Preview: Parasoft's SOAPtest 4.0

A wizard helped me set up a series of XML- and non-XML- specific penetration tests against a .Net Web service running in our labs. Because the service offers operations that interact with a database, the SQL injection tests were definitely of interest, even though SQL injection attacks through XML aren't much different from those that exploit other Web technologies, such as ASP, JSP and PHP.

Once the wizard was finished, I was shown a series of tests I could tweak in terms of parameter generation and success/failure conditions. SOAPtest can generate parameters from a static file, employ those specified by the user or take advantage of scripting languages such as JavaScript and Python. I was impressed with the multiple views of the requests SOAPtest generated. I could view the requests as raw XML, in a form requiring no expertise in XML or SQL, or as a hybrid with inputs for SOAP-specific values in the headers and body.

I left everything alone for the first run and with two clicks of the mouse ran all the penetration tests available--SQL injection, XML bombs (a more interesting way to say entity-expansion attacks), XPath injection and parameter fuzzing. Not surprisingly, the service failed most of the tests. I dug into the results, including the raw responses returned by the service, to find out why.

Many of the tests marked as failures appeared to be false positives. The SQL injection attack, for example, showed responses from the .Net server that clearly indicated the malformed request had never passed beyond the XML parser level and had not been sent to the back-end SQL Server database. Yet the service had returned a fault code and indicated the syntax of the request was invalid--which it was.

When I took a closer look at the parameters used for the SQL injection tests, I discovered that no real SQL injection exploits were involved. I ran this by the vendor, which told me that SOAPtest doesn't try to exploit vulnerabilities, but runs tests that let the software infer the vulnerability of a service. This makes a great deal of sense; even I had been leery of delivering an XML bomb to my service, knowing it would likely crash the server. However, while SOAPtest correctly found my services susceptible to SQL injection--in writing the code, I had deliberately left it vulnerable--I still wasn't entirely comfortable with the results, even after hearing Parasoft's lengthy explanations.I customized the SQL injection parameters to include '433011 OR 1=1 as the Order ID value for the GetInvoice operation, then reran the tests. Watching the response return through Ethereal's Network Protocol Analyzer, I could see a wealth of data returning when the service should have returned only one row of data, which is what a vulnerable service would do with such a query. But SOAPtest didn't flag the response as a failure; rather, it viewed the response as valid.

Parasoft suggested tweaking the Vulnerability Detector created for each instance of a test. This detector contains a list of keywords and regular expressions that, if found in the SOAP envelope, can be configured to flag the test as failing or succeeding. Specifically, the vendor recommended narrowing the keywords to filter out extraneous noise and reduce false positives by configuring the Vulnerability Detector to issue a failure status for only those error phrases that indicate the attack penetrated into the appropriate layer of the stack. For example, "ORA-" indicates an Oracle database error, and an SQL injection test that returned a response containing "ORA-" in the SOAP envelope would indicate the attack penetrated to the database layer.

Overall, the test suite is much improved over previous versions and worth a trial. I'm not convinced the penetration testing, though accurate, will catch every vulnerability in your Web services, but it's better than nothing, which is what most organizations have. It's a step in the right direction--and considering how far Parasoft has come with SOAPtest in other areas, I'd expect subsequent versions of its penetration testing will continue to improve as well.

Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. Write to her at [email protected].