Testing RESTful services with AppScan

AppScan is a pretty nifty Web App/Service vulnerability scanning tool. I believe it was originally developed by a company called Rational, which was later bought by IBM. AppScan can be used to test regular Web Applications, or Web Services like SOAP. The software carries a pretty hefty price tag, so you may or may not use it

At work, we use AppScan as part of our normal testing process. If you have used it before, you know that it has a pretty simple wizard to setup your scans. For web applications you simply plug in the url and simulate login. For SOAP, you give it the wsdl file and then just exercise the requests you want to test.

However, with REST its a bit different. There is no wsdl or web front end to attack. So to test REST, you have to do some fiddling. The method I am showing here uses manual exploration, the only way I know of to test REST. I am also going to involve using AppScan as a proxy for my requests. This may or may not be necessary, but I feel it is more solid.

Here it is:

Step 0: Generating test requests

– This step isn’t really a part of using AppScan, but its necessary. You have to determine which REST requests you want tested by AppScan. In my opinion, this is one of the benefits of a wadl.

– Create a list of requests that can recorded by AppScan for use in testing

– look through the wadl xml and identify the requests you are looking for. This may be difficult to those new at it, so here is a brief example:

<resources base=”http://your.webservice.base/rest/”&gt;

<resource path=”/”>

<resource path=”info”>

….

</resource>

<resource path=”doStuff”>

<param name=”id” style=”query” type=”xs:string” />

</resource>

</resource>

….

In this case, you might have some requests that look like:

thats a pretty brief example, but hopefully it makes sense. Essentially, you take the value of <resources base=…>, and begin to append values to it depending on the nesting of the xml. i.e, the <resource path=”/”> tells us to append a “/” to the end of the resources base value. We then can append a /info, which (not shown) has a <request> node directly beneat it. Etc.

In the second request we also see <param…> values that need to be appended. The first is always preceeded by a ?, while each following param is separated by an & sign.

Step 1: Setup AppScan for proxying

Open up AppScan.

– Exit the new scan wizard

– Scan -> Scan Configuration -> Communication and Proxy. Set ‘Don’t use Proxy’. Click OK.

– Tools -> Options. Make note (or set) the ‘AppScan Proxy port:’ value. Click OK.

– Go to Internet Explorer-> Internet Options -> Connections ->LAN Settings. Clikc the ‘use a proxy server…’ box. Set the address to 127.0.0.1 or localhost, and the port as was discovered in the previous step (NOTE: This port will change in AppScan every time it restarts). Click OK.

– Close Internet Explorer

Step 2: Dealing with values

Here is a reference to assist my explanation.

– Scan Configuration > Parameters and Cookies > Advanced: Custom Parameters.

– Add a custom param (+ sign in the top right)

– Enter a regular expression to match what will be found in the recorded request. If all of the params are user created, you may want to create a default/standard replace string.

– Select Path as the Location value.

– Click OK

– Return to the Parameters and Cookies tab. Add a custom parameter.

– Set type to Custom Parameter

– Under Reference name select the expression you previously created.

– Enable Track this parameters during scan

Set the Track type to whatever you need (usually Dynamic).

– Click OK

Step 3: Setup endpoint

–  In AppScan, Go to Scan -> Manual Explore. Click “yes” on the prompt if it appears.

– Enter the services starting URL. This is the base url of your service, or maybe your wadl file if you have one. i.e:

http://restws.myservice.net/ws/service/rest?_wadl&_type=xml

– You may also want to setup the appropriate test policy. This will make sure you dont use more tests than you desire. This can be found under the Policy header in the left menu.

Step 4: Manual Exploration

With the Manual Exploration recorder open, now open an internet explorer page.

– Go ahead and browse to each of the test requests you had previously created. Make sure that the parameters can be identified by the Custom Parameters filters we set up in Step 2.

– Once you are done, close IE, and the Manual Exploration browser.

– Click Okay (or signify which requests you want to use or not).

– AppScan then does it’s thing to generate tests for your requests. (you know if its working by looking at the bottem of AppScan and look for the “Completed Tests” portion. If the number is 0/0, it didn’t work).

– Go to scan -> test only

-voila!

Enjoy! let me know if it doesn’t work right!!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: