PingIntelligence detects and reports on Indicators of Attack (IoA), which represent anomalous behavior on each API. Detailed information about each Indicator of Attack is provided in the description. Examples include:
- Data extraction or theft.
- Anomalous API access patterns.
- Credential stuffing and password spraying.
- Account takeover with compromised credentials.
- Broken object or function level authorization.
- Data or command injection.
- Abnormal API sequence.
- Query string or header manipulation.
- Probing and fuzzing attacks.
- Extreme client activity.
For each API, the API JSON file (see API Security Enforcer Admin Guide for information) determines whether the IoA and other reports are associated with an OAuth token, API key, username, cookie, or IP address. An environment with multiple APIs can support a mixture of identifier types in a single AI Engine. Client identifier examples include:
- Tokens – When an API JSON file for an API is configured with OAuth2 token
parameter = true, then the AI Engine builds models based on token activity on the API. After the API is trained, the AI Engine then detects and reports on IoAs associated with the tokens used by clients accessing the API. Analyzing token activity is recommended when access tokens are present as it is a unique client identifier that eliminates the issue of multiple clients sharing an IP address behind a gateway.. - API Keys – When the API JSON file for an API is configured with an API Key either in
the query string or the header, then the AI Engine trains and detects IoAs based on
the API Key values. For example, if there are two API Keys in the system,
X-API-KEY-1 and X-API-Key-2 with values as api_key_1 and api_key_2, then a total of
four client identifiers are added to blacklist of ASE:
- X-API-KEY-1:
api_key_1 - X-API-KEY-2:
api_key_2 - X-API-KEY-1:
api_key_2 - X-API-KEY-2:
api_key_1
- X-API-KEY-1:
- APIs with cookie – When the cookie parameter is configured, most IoAs are reported with cookie identifiers, the exception being pre-authentication attacks (such as client login attacks). Configuring the cookie parameter is recommended when cookies are present as it is a unique client identifier that eliminates issues identified below with IP addresses.
- Cookies – When the API JSON file for an API is configured with the cookie parameter, the the AI Engine builds models and detects IoAs for cookie identifiers, the exception being pre-authentication attacks (such as client login attacks). Configuring the cookie parameter is recommended when cookies are present as it is a unique client identifier that eliminates the issue of multiple clients sharing an IP address behind a gateway.
- IP Address – When neither the cookie nor token parameters are configured, all IoAs are
reported with the client IP address which is determined based on the following:
-
XFF header present: The first IP address in the XFF list is used as
the client identifier. When forwarding traffic, load balancers and other
proxy devices with XFF enabled add IP addresses to the XFF header to provide
application visibility of the client IP address. The first IP address in the
list is typically associated with the originating IP address. Note:
XFF is not always a reliable source of the client IP address and can be spoofed by a malicious proxy.
-
No XFF header: When no XFF header is present, the source IP address
of the incoming traffic is used as the client identifier. In this
configuration, make sure that the incoming traffic is using public or
private IP addresses associated with the actual client devices, not a load
balancer or proxy device on your premise. Note:
When a load balancer or other proxy without XFF enabled is the source of the inbound traffic, then all client traffic will be associated with the load balancer IP addresses. This configuration will not provide effective attack reporting unless cookies or tokens are used.
-
XFF header present: The first IP address in the XFF list is used as
the client identifier. When forwarding traffic, load balancers and other
proxy devices with XFF enabled add IP addresses to the XFF header to provide
application visibility of the client IP address. The first IP address in the
list is typically associated with the originating IP address.
- Usernames – Unlike other client identifiers, username is not configured in
the API JSON file. Username information is captured in the following ways:
- When the incoming request has a JSON Web Token (JWT), the user name can be extracted by ASE. For more information, see Extract user information from JWT in sideband mode or Extract user information from JWT in inline mode.
- When the incoming request has a custom header with user information, then the username is extracted from the custom header. For more information see, Extract username from custom header in sideband mode or Extract username from custom header in inline mode.
- When deployed in sideband mode, a platform (for example API Gateway) which supports capturing username information through token introspection can pass the user name through its sideband calls. API gateway integrations that support sending username information to PingIntelligence include:
The AI engine will not detect username attacks for requests where the server responds with an HTTP 401 Unauthorized Error code. This will prevent blocking of a valid user if an attacker tries to impersonate the user. Also while reporting an abnormal sequence, if username is available with the API ecosystem, the AI engine reports username or else it reports OAuth token.
To change the client identifier used for IoA detection for an existing API, update the API JSON configuration to provide the desired client identifier. To re-train the model for this API, click on the Dashboard reset training in PingIntelligence Dashboard or save the API JSON file with a new name.