Threshold-based DataGuard for BOLA Prevention

1) Why?

BOLA(Broken Object Level Authorization) is the #1 API attack in the OWASP API Top 10. While the attack is now quite well-known, preventing it is still difficult because of its logic.

2) 3 attack stages of BOLA attack

BOLA has three attack stages, 'Reconnaissance' -> 'Actual Attack' -> 'Data exfiltration'.

F5 XC has a feature, 'Malicious User Detection', for the 'Reconnaissance' phase, and behavior-based detection will be upcoming for the second phase, 'Actual Attack.'

However, we don't have a good solution for the 'Data Exfiltration' phase in a BOLA attack.

3) Why is the current DataGuard not enough?

In a BOLA attack, an attacker normally targets the API endpoint that is potentially vulnerable to the BOLA exploit. API endpoints normally provide PII or critical data to legitimate users. However, once the attacker exploits the BOLA vulnerability, the target API endpoint will return other users' information to the attacker.

In other words, the API endpoint must be able to provide the PII or data to legitimate users. If we configure the current DataGuard, it will block or trigger the alert even if normal users initiated the traffic.

4) How does the feature work?

Threshold-based DataGuard is similar to a 'Rate-limiting' feature. The difference is that the 'Rate-limiting' feature blocks traffic when it reaches the configured threshold, while the 'Threshold-based DataGuard' will mask sensitive data when it reaches the configured threshold.

Let's say, XC is configured with the threshold '10 reqs / minute' in the 'Threshold-based DataGuard' and the pattern is configured with Regex to detect the 'SSN'. Then, XC will not block/mask/alert about the traffic with SSN until a unique client accesses 'SSN' more than 10 requests in a minute period. Once the client accesses the SSN more than 10 times per minute, Threshold-based DataGuard will trigger the alert or block/mask the SSN with the 11th try.