Skip to main content
Version: 2.9

API Protect Directives

The following ARMR rules support the API Protect api() and input() directives:

  • DNS

  • Filesystem

  • Socket

  • Process

Both the api() and input() directives are an additional condition of use when the given rule is applicable. These directives complement the primary selector directive for each rule, which in most cases should be a wildcard. For example, the read() or write() directives in the case of the Filesystem rule. That is, in general, an ARMR rule configured for API Protect should apply to "all DNS requests", "all files and folders", "all sockets" and "all external processes". This is covered further in the Recommended API Protect Policy section.

Neither api() nor input() is valid in an ARMR rule with an action of ALLOW. That is, it is not possible to create an ARMR whitelisting rule which would only be applicable in the context of processing API requests.

apiapi() is used to specify either that the rule is only applicable to when the application is performing operations needed to satisfy RESTful API processing HTTP requests. Using the following configuration options, this directive can be tailored to target all API endpoints, or a specific selection of one or more API endpoints.Valid values for the api() directive are:- any: the wildcard value. When api(any) is specified in a supported rule, the rule is applicable for all API processing HTTP requests.
  • This value can not be combined with any of the other valid values described below.

  • a single endpoint, for example: /resources/v2/file. When api("/resources/v2/file") is specified in a supported rule, the rule is applicable to that single endpoint only.

  • multiple endpoints, for example api("/api/v3", "/api/v4"). When multiple endpoints are specified in a supported rule, the rule is applicable to all specified endpoints

    • multiple endpoints are expressed as a list of comma separated strings as in the example above.

  • when specifying API endpoints, the wildcard character (*) is supported to cover a range of endpoints. This can be specified as:

    • a prefix */endpoint

    • a suffix /api/v2/*

    • both a prefix and a suffix */cars*A value must be specified for the api() directive. | | input | input() is already available in a number of ARMR rules for existing security features, such as those which prevent injection based attacks.This allows the user to specify the source of the untrusted data. The following three sources are supported:- http data introduced via HTTP/HTTPS requests

  • database data introduced via JDBC connections

  • deserialization data introduced via Java or XML deserializationThe rule will trigger if the source of the untrusted data matches that specified in the rule.If no value is specified then a default value of http is used.An exception will be thrown if an unsupported value is provided.This directive should be understood as a condition for when the rule is applicable. Specifically, the rule will be applicable where:- DNS: the host name was provided by text that originated from the above specified source(s).

  • Filesystem: any portion of the file or folder name was provided by text that originated from the above specified source(s).

  • Socket: the host name, IP or port was provided by text that originated from the above specified source(s).

    • input() is available for the Socket connect() rule only.

  • Process: any part of the command to execute was provided by the text that originated from the above specified source(s). |

The following is an example of how the ARMR DNS rule may be configured for API Protect:

dns("API block any DNS address resolution"):
    lookup(any)
    api(any)
    input(http)
    protect(severity: High)
enddns

That is, this rule will protect against DNS address resolutions for all API endpoints where the host name was provided by text that originates from an HTTP/HTTPS request.