ThreatScript Definitions¶

ThreatScript Definitions are written in ECMAScript (basically the same as JavaScript). The ThreatScript definitions return a Result object which indicates whether a match was observed.

ThreatScript Example¶

Below is an example of a ThreatScript that triggers if the web-page has a form element.

/*
 * Name: Example.General.Has_Form_Tag
 * Version: 1
 * ID: 1000000
 * Message: Indicates if the page has as a form tag
 * Severity: Low
 */

importPackage(Packages.ThreatScript);
importPackage(Packages.HTTP);

function analyze( httpResponse, operation, variables, environment, defaultRule ){

    var parser = httpResponse.getDocumentParser();
    var location = new URL( httpResponse.getLocation() );

    //Get a list of all script tags
    var tagNameFilter = new TagNameFilter("form");
    var nodesList = parser.extractAllNodesThatMatch(tagNameFilter); 
        if( nodesList.size() > 0 ){
         return new Result( true, "A form was detected" );
    }

    return new Result( false, "No forms detected" );
}

Meta-Data¶

ThreatScripts must provide a meta-data that indicates the following information:

Definitions must have a name that is composed of three parts: a category, sub-category, and name. The part are separated by periods (like "category.subcategory.name"). The category and sub-category are important because the user can create exceptions and disable definitions by category or sub-category. Therefore, it is important that you use category names that makes sense; otherwise, the user may disable or enable your definition inadvertently.

In some cases a definition may be created for a specific site-group or rule. It is recommended that the definition be named such it is clear it is site-group or rule specific. Oftentimes, this done by appending an underscore to the category name (e.g. "_Acme.InformationLeak.ConfidentialDocumentFound").