How Access Control Vulnerabilities are Exploited

Access-Control vulnerabilities are incredibly commonplace in today’s APIs. They’re not hard to fix, but they’re hard to continuously validate and keep in check as the code base, and features grow. Hackers love these weaknesses as they’re hard to detect and mitigate at the network or firewall level.

For example, take this simple scenario.

Let’s assume certificate provider has these APIs

POST /api/certificate // creates a new certificate

POST /api/certificate/{UID}/renew // renews a certificate by UID

DELETE /api/certificate/{UID}/revoke // revokes a certificate by UID

PUT /api/certificate/{UID} // update certificate passphrase by UID

GET /api/certificates // Lists all certificates

Typically a customer would request a new certificate by calling the create endpoint, i.e., #1. The API then returns the newly created certificate along with the UID. Later on, if the customers want to renew, update or revoke certificate they can do this by merely using the mapped UID.

If there is a flaw in the products business logic, and it doesn’t correctly check all the incoming UIDs against the caller’s credentials to validate if the user is entitled to the UID then this flaw would have allowed the attacker to use an altered or phished UID’s that belongs to other customers and perform automated attacks.

Why it’s hard to keep the business logic working correctly:

Because the logic grows crazily, and here is an example of that.

loggedInUser.isOwner(UID) // v1: only owner can access the certificate.// v2: let’s allow the role collaborators access the certificates// v3: let’s allow the role support staff to help customers// v4: let’s allow role reader to only download the certificate

Consequences of the breach

These attacks are hard to detect and can take months before it’s known, and also, it could incur a huge cost on both the vendor and on the customers. The vendor would have to pay for forensics, legal and PR. For some customers replacing their certificate may incur a considerable cost, as they might be used in payment terminals and other hard-to-reach devices.

How security teams can protect APIs targeting these flaw?

The only way to prevent is to continuously detect and fix them early in the development cycles.

You need 100% automated coverage either in-house build or using an API Security Scanners.