is a pretty nifty Web App/Service vulnerability scanning tool. I believe it was originally developed by a company called , which was later bought by . AppScan can be used to test regular Web Applications, or Web Services like . 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 file and then just exercise the requests you want to test.
However, with 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=” <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
– 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:
– 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!!