For each API, the API JSON file (see API Security Enforcer Admin Guide for information) determines whether the attacks and other reports are based on OAuth token, API Keys, username, cookie, or IP address. An environment with multiple APIs can support a mixture of identifier types in a single ABS AI Engine. Client identifier examples include. Client identifier examples include:
API using OAuth2 tokens – When an API JSON file is configured with OAuth2 token
parameter = true, then attack information is associated with the OAuth2 access token used by the hacker. Configuring the OAuth2 token parameter is recommended when access tokens are present as it is a unique client identifier that eliminates issues identified below with IP addresses.
APIs using API Keys:When API JSON file is configured with API Key either in the
query string or the header, ABS detects attacks on the value of the API Key. 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:
- APIs with cookie – When the cookie parameter is configured, most attacks 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.
API JSON without a cookie or token parameter – When cookie and OAuth2 token
parameters are not configured, all attacks 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.
REST API attack based on username:
In some sideband deployments, for example, PingAccess with PingFederate, the username of the accessing client is available via RFC 7662 token introspection or other techniques. ABS AI Engine detects attacks based on the username. Unlike other client identifiers, username is not configured in the API JSON file. The ABS AI engine detects the username from the metadata sent by ASE.
To change the client identifier for an existing API, save the API JSON with a new name and update the configuration to include the new client identifier parameter. ABS then re-trains the model for this API and starts detecting attacks.