Field Report Updates From the API Security Front Lines
Chuck Herrin, CISSP, CCSP, is the Chief Technology Officer & Board Member of Wib. Many attackers exploit API vulnerabilities and weaknesses as part of their offensive operations. So, your defense should be informed by the offense. This article by Chuck discusses updates from API security frontlines.
When you find an API exposed to the outside world, it exposes your business logic and your back-end system. That’s a symptom of something that failed upstream. Somebody should have known that you were exposing this interface to the outside world before it showed up in the outside world. We change the attack surface when we change from a monolithic to a microservice-based architecture.
How and why API security differs from traditional web application security?
- Fundamentally, when the attack surface changes, the architecture changes, and you change what’s exposed to the outside world. For APIs, by design, this is not a bug; it is a feature. APIs expose application logic and often change rapidly.
- The attacks are different. The attacks are against business logic, and they tend to be chained. We still see injection, cross-site scripting, and SQL injection. But the ones we’re most worried about, the more difficult ones to address, are broken object level, authorization, and broken functional level authorization. Attacking APIs is mostly making unexpected requests and failures to scope authorization resources.
- Our defenses need to be different. Traditional rule-based defenses like Web Application Firewalls (WAFs) can neither detect nor defend against logic-based attacks.
What are the problems that companies need to address?
- Visibility – If you cannot see the risk, you cannot mitigate it. The risks you may face will always be a blind spot. About 50% of APIs are invisible and so, unmanaged, which can cause security issues.
- Ownership – Once an issue is found, who I assign it to is a fundamental problem. Who owns the issue and will help fix the issue?
- Tooling for logic-based attacks. WAFs and API gateways serve their purpose and are good at what they were designed to do. But they are not designed to understand the business logic.
- Management of API development velocity. A very common problem is customers that are either worried about security, so it’s slowing them down, or security can’t keep up. Sometimes security is still operating in the once-a-quarter, manual pen test release process. That doesn’t work in an agile microservice world at all. We must have tooling, capabilities, and process knowledge to resolve this issue.
Threat modeling and Attack Surface Management
You must know the assets, actors, interfaces, and actions. You have to identify your trust borders. At these trust borders, you look what actors can do and how they can perpetuate attacks such as spoofing, tampering, repudiation, information disclosure, denial of access, and escalation of privilege. Suppose you’re not monitoring your APIs. In that case, you don’t have any idea about the types of attacks they’re capable of carrying out, like what the vulnerabilities are in the code or what attacks are taking place in the production traffic. Unless you simulate attacks to validate what you’re vulnerable to, you end up escalating issues that look like problems that actually aren’t and waste time.
Case Study
We worked with a top bank with approximately $100 billion in assets. With a Live account, our attack simulation found vulnerabilities. If you look at direct attacks, you may never find any vulnerabilities. Attackers will use whatever entryway they can, not the one you want them to use. We crafted the queries directly. We found that the attack surface for this type of attack varies based on international exchange rates because that impacts the rounding. This was a business logic attack. WAFs and API gateways were not designed to understand this. We built in the required security checks to resolve this issue.
To conclude, APIs and their vulnerabilities are blind spots, and you can’t manage what you can’t see. You can’t monitor what you can’t see. The way that we have to approach this is with as many lenses as possible. Once we have our findings, we apply insight and context and understand business value. When things look suspicious, we simulate attacks to validate our findings because the last thing you want to do as a security practitioner is starting spraying your developers with false positives. Once we know the actual vulnerabilities, we can address them.
