IAST configuration file

You can configure a JSON file to override the default IAST settings, and report only the vulnerabilities you want to know about.

Structure

The configuration file is user-config.json, and it can be deployed either before the agent starts, or during runtime. Changes may take few seconds to take effect. When a file is added, any previous version is disabled. If the file is deleted, IAST returns to its default configuration.

Sample file:
{   
  "logging": {
     "logLevel": "ERROR",
     "stdoutLogLevel": "DEBUG",
     "maxSizeLogFileMB": 100
  },
   "monitoredApps": [ 
    "app1", "app2"
  ],
  "asoc": {
    "reportToAsoc": true,
    "asocPollingIntervalInSec": 10
  },
  "memoryThreshold": 0.85, 
  "ignoredMethods": [ 
    "DriverManager.getConnection" 
  ], 
  "ignoredNonSecureCookies": [ 
    "myCookieName" 
  ], 
  "ignoredNonHttpOnlyCookies": [ 
    "anotherCookieName" 
  ], 
  "securityRules": { 
    "CheckCsrf": false, 
    "CheckServerHeader": false, 
    "CheckXPoweredBy": false, 
    "CheckXAspNetVersion": false 
  }, 
  "safeHeaders": ["MySafeHeader", "MyOtherSafeHeader"], 
  "safeCookies": ["MySafeCookie", "MyOtherSafeCookie"], 

  "hooks": [ 
    { 
      "targets": [ 
        "com.ibm.myApp.common.MyEscapeUtils" 
      ], 
      "methods": [ 
        "myEscapeHtml" 
      ], 
      "parameters": [ 
        "java.lang.String" 
      ], 
      "rules": [ 
      { 
        "type": " sanitizer", 
        "from": "return", 
"vulnerability": "CrossSiteScripting.Reflected" 
      } 
    ], 
      "requiresSuperTypes": false 
    } 
  ] 
} 

Deployment

You can deploy the IAST agent through the ASoC RESP API or from a local file. In both cases you can update while IAST is actively monitoring, and the update will take effect within a few seconds.

REST API

  1. Send request FileUpload. The response includes FileId.

  2. Update your IAST agent with the FileId you received.



Local file

You can deploy the configuration file by copying it to a directory on the server. The deployment location is usually the server temp folder. last prints the location to stout.

Example:

Table 1. Typical deployment directories
Tomcat /home/Secagent
WebSphere /home/was/Secagent
WebSphere Liberty /home/default/Secagent
JBoss Wildfly /home/jboss/Secagent
Open Liberty /tmp
WebLogic /home/oracle/Secagent

Options

Logging

The following logging options can be controlled through the configuration file.
Field Values Description
logLevel NONE, ERROR, WARNING, INFO, DEBUG, TRACE

Default: DEBUG

The logging level of IAST log file.
Note: Setting the log level to TRACE can adversely affect IAST agent performance.
stdOutLogLevel ONE, ERROR, WARNING, INFO, DEBUG, TRACE

Default: INFO

The logging level of IAST events to stdout.
Note: Setting the log level to any value other than INFO will adversely affect IAST agent performance.
maxSizeLogFileMB Integer

Default: 20

To avoid large files, when the IAST log file reaches a predefined maximum (in MB), it is zipped and the new logs are saved to a new file. Set the maximum file size with this field.

Communication with ASoC

These fields control communication with ASoC.
Field Values Description
reportToAsoc TRUE, FALSE

Default: TRUE

Enable/disable reporting to ASoC.
asocPollingIntervalInSec Integer

Default 10

Define how frequently (in seconds) IAST reports issues detected to ASoC.
Note: Reducing the interval below 10s can create a large overhead on network communications with ASoC. Increasing the interval requires higher memory usage and may result in data loss if the IAST agent is stopped before the latest data is sent to ASoC.

General

Field Values Description
monitoredApp "monitoredApps": [ "app1", "app2"] will limit monitoring to these apps only. Names the web applications running on the server that are to be monitored by IAST; others will be ignored.

If not defined, all apps on the server are monitored.

The app name is generally derived from the WAR file name, so demo.war is simply called demo. For details and exceptions, refer to App names.

memoryThreshold Any value between 0.5 - 1.0

Default: 0.95

If the client's JVM memory usage runs above this threshold, IAST will automatically disable itself to prevent OutOfMemoryError. When memory usage decrerases below the threshold IAST will automatically enable itself again.

Filtering

Filter exploits by namespace
Field Values Description
ignoredMethods array of strings

Default: None

This field can be used to filter out exploit issues (Cryptography.PoorEntrpy, Cryptography.InsecureAlgorithm, etc.) based on namespace. Note that this will exclude all issues from the namespace.
Example:

To filter out this issue and all issues from com.hcl.appscan.systemtests.SystemTests, we can add:
"ignoredMethods": ["com.hcl.appscan.systemtests.SystemTests"]
Ignore reports on insecure cookies
Field Values Description
ignoredNonSecureCookies, ignoredNonHttpOnlyCookies array of strings

Default: None

IAST reports when secure attribute is not set or http-only attribute of a cookie is set. To filter out a specific cookie, add the cookie name to the configuration file.
Example:

To filter out this issue we can add:
"ignoredNonSecureCookies": ["myCookie"]

Disable security rules

Example:
"securityRules": { 
    "CheckCsrf": false, 
    "CheckServerHeader": false, 
    "CheckXPoweredBy": false, 
    "CheckXAspNetVersion": false 
  } 
} 

Description: All security rules are enabled by default. Through the configuration file, you can disable some of the report types. You can specify only the fields that you want to disable, all others will remain enabled.

For example: “CheckCsrf” : false will disable reorting for all issues of this type.

Disable injection by header name or cookie name
Field Values Description
safeHeaders, safeCookies array of strings

Default: None

You can declare a header or a cookie value as safe by its name. This will cause IAST to stop tracking input from this header or cookie, so any injection from this value will not be reported.
Tip: HTTP Header names are case in-sensitive.
Example:

The source of the following Cross Site Scripting issue is a header called input2. To filter all issues that are caused by this input we can add:
"safeHeaders": ["input2"]

Hooks

In some cases it can be useful to add hooks to IAST, to add behavior of the application under test. For example, if we have a proprietary sanitization method that IAST does not recognize, we can tell IAST to clean every string that enters this method. Note that in that case IAST will not know what the method actually does, so it is up to the user to verify that the sanitization is correct and sufficient for their security requirements.

Example 1: Sanitization for a specific vulnerability

The following configuration will define the method myEscapeHtml in class com.myApp.common.MyEscapeUtils as a sanitizer for cross site scripting, and this will cause the return value to be cleaned. It will still report if the return value ends up in an SQL sink, for example.
"hooks": [ 
    { 
      "targets": [ 
        "com.myApp.common.MyEscapeUtils" 
      ], 
      "methods": [ 
        "myEscapeHtml" 
      ], 
      "parameters": [ 
        "java.lang.String" 
      ], 
      "rules": [ 
      { 
        "type": "sanitizer", 
        "from": "return", 
"vulnerability": "CrossSiteScripting.Reflected" 
      } 
    ], 
      "requiresSuperTypes": false 
    } 
  ] 

Example 2: Sanitization from all vulnerabilities

The following configuration will define the method myEscapeAll in class com.myApp.common.MyEscapeUtils as a sanitizer all vulnerability types, and this will cause the return value to be cleaned.
"hooks": [ 
    { 
      "targets": [ 
        "com.myApp.common.MyEscapeUtils" 
      ], 
      "methods": [ 
        "myEscapeAll" 
      ], 
      "parameters": [ 
        "java.lang.String" 
      ], 
      "rules": [ 
      { 
        "type": " sanitizeAll", 
        "from": "return" 
      } 
    ], 
      "requiresSuperTypes": false 
    } 
  ]