Working with custom security checks in Invicti

How Invicti runs security checks

Operating as a black-box web vulnerability scanner, Invicti probes and examines your application from the outside, exactly as an attacker would. During testing, Invicti visits every link that its crawler detects and makes requests to all input points in detected resources, including the URLs used to reach these resources. Next, it safely performs test attacks on the target application by sending suitable attack payloads to the identified input points. Finally, it analyzes the responses to detect vulnerabilities in the web application.

Built-in and custom security checks

To identify vulnerabilities, Invicti uses thousands of built-in security checks, incorporating over a decade of continuous security research and development for maximum coverage and accuracy. In fact, over 94% of direct-impact vulnerabilities will be confirmed automatically by the scanner with 99.98% accuracy, so you know you can trust the results.

However, every application environment is different, so occasionally you may want to add a custom check to test application-specific assets or payloads. With its custom scripts for security checks feature, Invicti Enterprise lets you write custom security checks in JavaScript. Once they are added to your account, you can use custom scripts in a custom scan policy to scan specific URLs or entire sites. 

Types of custom security checks in Invicti

Custom security checks in Invicti fall into four categories, depending on the scope of testing and type of attack activity: active, passive, singular, and per-directory.

Active security checks

With custom active security checks in Invicti, you can define your own attack patterns. During the test attack phase, Invicti will inject these custom attack patterns into parameters discovered by the crawler. Each attack pattern you provide in your custom script will result in one HTTP request for each parameter discovered by the crawler. 

You can specify the type of parameters that will be targeted for injection. For example, you may choose to attack only JSON parameters but not query string or POST body parameters. After Invicti sends the attack request and receives a response, you can then examine the HTTP response to decide if the injected attack pattern has revealed a vulnerability.

Passive security checks

Passive security checks do not issue any extra HTTP requests during scans. You can write passive security check scripts to analyze the responses received by the crawler for each endpoint. If the response contains sensitive information or other undesirable data, you can then raise a new vulnerability in Invicti.

Singular security checks

These are similar to passive security checks but executed only once for each scan, which is useful for checking headers and similar data. You can analyze the response of the target URL for the scan and raise vulnerabilities if necessary.

Per-directory security checks

These are very similar to active security checks but executed once for every directory (URL segment). Generally, you should write per-directory security checks if you want to check for the existence of certain files in the directories of the target web application, for example, known resources that are not linked anywhere in the web application.

Writing a custom security check

Custom security checks in Invicti are coded in JavaScript, so you don’t need to learn another scripting language to write them. Our support page provides detailed documentation about writing security checks, but let’s take a quick look at a simple script to learn the basics. Here is a sample script for a custom active security check:

var attacks = [
  {
    id: '8613F6DB-9AD2-4E45-9B8F-308C810FF7DB',
    name: 'My New Pattern',
    attack: '%27AND+1%3dcast(0x5f21403264696c656d6d61+as+varchar(8000))+or+%271%27%3d%27',
    attackUsage: AttackUsages.Json + AttackUsages.Xml
  }
];

function analyze(context, response) {
  if (response.Body.indexOf('iNj3Ct3D') > -1) {
    return new Vulnerability(VulnerabilityType.PossibleSqlInjection);
  }
}

The script consists of two parts: a list of attack definitions and a response analysis function. An attack definition includes the following properties: id, name, attack, and (optionally) attackUsage. The id must be in the GUID format and unique. The name is what will be displayed in your custom scan policy, while the attack property specifies the payload that will be injected into request parameters.

The optional attackUsage property defines the type of parameters into which the attack will be injected (query string and POST parameters by default). You can combine multiple values using the addition symbol. Invicti automatically encodes the payload using the right method for the parameter type, unless you add the optional attackEncoded property to indicate that the attack is already encoded.

The second part of the script is response analysis. The analyze() function is executed for every response to an attack request made during the scan. The function takes two parameters: context and response. The context variable includes information about the current attack context, while response represents the HTTP response returned by the web server in reaction to an attack pattern specified in attacks.

If you decide that the response indicates a vulnerability, you can return a new Vulnerability object with a suitable vulnerability type. In this example, the function checks if the response body contains a specific test string and if so, it returns a Vulnerability object corresponding to an SQL injection.

Adding your custom security check to Invicti Enterprise

Once the script is ready, you will need to get in touch with your in-house Invicti Enterprise administrator or a Invicti support engineer to add the script to your account (depending on the deployment type). You then need to decide what type of vulnerability the script will raise and specify a vulnerability name, severity, and description to display in the Invicti UI and reports. The next step is to create a custom report policy, add your custom check to it, and finally add the script to your account (again, for on-demand deployments, this is done by a Invicti support engineer).

With your custom security check ready, you can now scan a specific URL or an entire site to see if Invicti identifies the vulnerability type defined in your script. Scanning a specific URL is only possible after Invicti has scanned the whole site at least once. After that, you can navigate to Custom Scripts under Policies in the main menu and execute your custom script after selecting the URL. When Invicti executes your custom security check, you will see a message indicating whether a vulnerability was found. For more information, see Executing a custom script on a web page.

Scanning targets with your custom script

To scan an entire website with your custom security script, you first need to create a custom scan policy. As a Invicti support engineer has already created a custom report policy for your custom checks, you can now start scanning your website to identify the vulnerability specified in your script. To do this, simply create a new scan and select your custom scan and report policies. For more information, see Scanning a website with a custom security script.

If vulnerabilities defined in your custom script are found during the scan, they will be displayed in the scan report and the Sitemap tree under the relevant site node. If vulnerabilities are expected but not found, you may want to check your script code. You can modify and execute the script as many times as you want until you see the expected result in the report and the Sitemap tree.

Complementing Invicti’s highly accurate vulnerability detection technology with Proof-Based Scanning, the ability to write custom testing scripts lets you maximize test coverage by adding application-specific checks. For more information and FAQs about working with custom scripts in Invicti, see Custom scripts for security checks in Invicti Enterprise.