Script / Custom Scan

Introduction

The Custom Scan follows the basic model of the other parameter-based Security Scans but requires you to specify a script (Groovy, Javascript or Java) that will provide the values to send for each permutation, giving you maximum flexibility with how you can provoke your target services.

The configuration dialog has the common elements:

1. The list of parameters that will be mutated by the script
2. The script itself (see example below)
3. The Security Assertions used for validating the response
4. The Execution Strategy settings

The script has access to the following objects:

• parameters - a map with the defined parameters names as keys, specify the desired mutations here
• securityScan - the instance for this SecurityScan
• testStep - the underlying TestStep being scanned
• context - the SecurityTestRunContext
• log - the standard scripting log

The script is expected to create the desired mutation values in the supplied "parameters" object and return true if these should be use for a SecurityScan request, if the script returns false the SecurityScan is finished.

A Fuzzing Example

Creating entirely random inputs for a target service is a common way of trying to provoke security vulnerabilities (often called Fuzzing). Lets create a simple script that creates random input strings between 5 and 15 characters in length for 10 requests:

import org.apache.commons.lang.RandomStringUtils

// check counter
if( context.fuzzCount == null )
  context.fuzzCount = 0

// randomize 5 to 15 characters
def charCount1 = (int) (Math.random() * 10) + 5
def charCount2 = (int) (Math.random() * 10) + 5

// use method in Commons Lang
parameters.password1 = RandomStringUtils.randomAlphanumeric( charCount1 )
parameters.username1 = RandomStringUtils.randomAlphanumeric( charCount2 )

return ++context.fuzzCount < 10

Running this for a login service gives the following entries in the Security Log:

You can see the different random strings generated for each parameter and request, fortunately none provoked an error as far as our assertions could tell. Since the idea with fuzzing attacks is usually to run them for a prologned period of time, the above script could be modified to run thousands or even millions of requests in the hope of provoking some kind of errornous or unexpected behaviour in our target service.