Tools and Techniques for Assessing Authenticated Web Services

A web application security assessment that I recently performed included a web services component. These web services existed to provide equivalent functionality to non-browser-based client applications, as well as administrative functions for authorized users. To thoroughly test this portion of the application would require tools tailored to web services, with two qualifications beyond what I'd required from software tools used in previous web service assessments:

• the web service was hosted only over an SSL-encrypted, HTTPS connection; and
• traditional, cookie-based authentication tokens were required to interact with most of the web service methods.

Several tools that I've previously utilized were outdated and not capable of meeting either or both of these requirements - namely, WSFuzzer (version 1.9.5 released September, 2010); and WebScarab (version 20070504 from May, 2007). Several alternative options exist, fortunately.

WSDigger, from Foundstone, includes discovery and audit functionality via built-in attack plug-ins, but has not been updated in several years, and is not natively capable of HTTPS connections. However, by configuring an SSL tunneling proxy such as stunnel to listen on the local loopback interface, and redirect connections to the web service, WSDigger can be used to interact with the target web service. The 'WSDL' and 'Service URL' fields should be populated with the stunnel listener's local address and port, via HTTP; this connection is then forwarded to the web service over an HTTPS connection, and requests the path specified in the 'Service URL' field.

The 'Get Methods' button successfully retrieved the web service methods, such as 'SaveUserToAddressBook', 'InsertNewUser', 'SendDICOM', etc.

WSDigger can connect through a local web proxy application, such as Burp Proxy, using the local system proxy settings.

A call to the 'GetWeatherReport' method, specifying a 'ZipCode' string, is captured in a local proxy as an XML SOAP request.

WSScanner is a similar tool with discovery, vulnerability scan, and fuzzing components, in addition to acting as a SOAP proxy. Although WSScanner claims to support HTTPS URLs, my experience indicates otherwise. The tool does not provide built-in support for passing authentication credentials, using system proxy settings, or otherwise configuring connections through a local proxy.

The stratsec Web Method Search tool, used to enumerate unpublished web service methods, is able to interact with SSL-encrypted web services, and can also be configured to use a proxy.

A default list of verbs and nouns used in requests to guess method names.

The Metasploit Framework includes a similar SOAP verb/noun brute-force scanner, which is capable of SSL connections.

SoapUI, one of the most full-featured tools to interact with and test web services, can interact with HTTPS-based services.

The 'Authenticate Preemptively' option instructs the application to send specified HTTP Basic credentials with each request, providing a way to authenticate with web services that support this mechanism.

The 'Proxy Settings' option allows the user to pass requests and receive responses through a local web proxy application as well.

However, when attempting to access HTTPS-based services using a local proxy, soapUI returns a generic error message, due to the untrusted SSL certificate presented by the local proxy. Unlike with a web browser, there is no apparent way to ignore or override this error.

By starting stunnel once again as an SSL redirector, configuring soapUI to connect to the stunnel listener via HTTP, and passing these connections through the local web proxy, we can view and modify requests and responses to and from the target HTTPS-based service.

Finally, we can utilize the soapUI TestCase option 'Maintain HTTP Session', if the service supports authentication via HTTP Basic credentials.

Alternatively, in the case that the target service requires cookie-based token authentication, we can manually authenticate using a web browser (e.g., submit credentials to a login form), and examine the cookie value(s) set by the service to maintain an authenticated session state, using the local proxy. Then, configure Burp Proxy to automatically modify future requests to the stunnel listener, adding the required Cookie header and values.

Subsequent requests from the soapUI application will be modified by the intercepting proxy to include currently-authenticated sesion token values, forwarded to the local stunnel listener, and redirected to the target HTTPS service. Responses, conversely, will be received by the stunnel listener, converted to plaintext HTTP, forwarded to the intercepting proxy for viewing and/or modification, and ultimately received and displayed by soapUI.

Though slightly convoluted, this method of chaining an intercepting web proxy and SSL tunneling proxy allows us to interact with and test HTTPS-based, authentication-required web services, using a robust testing tool.

An alternative, ultimately-customizable solution is to script a simple web service client -- using, for example, Ruby's SOAP::WSDLDriver class. This script can be written to connect through a local proxy, thereby providing request modification, fuzzing, and authentication capabilities, and can log requests and responses to a local file for further analysis.