Edulog API Breach Explained: BOLA Risks & Fixes
A deep dive into the Edulog Parent Portal API breach, what caused the BOLA exposure, and how teams can prevent similar API attacks.
.png)
What Happened to Edulog Parent Portal Platform?
On September 13, 2023, researches from Tenable discovered a vulnerability in Edulog’s Parent Portal API that allowed anyone who created an account to bypass school registration safeguards and gain “unfettered access” to any information available.
What was exposed through this API flaw?
- Student names
- GPS locations of their assigned busses
- Parent contact information
How could attackers take advantage of that flaw?
Anyone who created an account could manually submit requests directly to the APIs endpoints. This would allow them to retrieve any of that information from above without ever even having to register for the schools.
OWASP #1 and #2
Broken Object Level Authorization
Broken request validation allows an attacker to perform an unauthorized action by reusing an access token. This was used by the Tenable researchers who were able to pull information from other users.
Broken Authentication
Broken user authentication allows attackers to impersonate legitimate users. The Tenable researchers did this by manually submitting requests to the APIs endpoints. The API treated the researchers as if they were the account owners.
How to prevent this from happening to you
Edulog was not the first educational platform to have vulnerable APIs and they certainly won’t be the last but there are steps to prevent something like this from happening. Here’s what you can do to protect your company from BOLA and Broken Authentication:
Enforce Robust Authorization Mechanisms
Enforcing robust authorization mechanisms is the first step any organization should take to combat BOLA vulnerabilities.
Many organizations think their APIs are secure because they have strong authentication. But that's not really going to help a whole lot when it comes to BOLA vulnerabilities.
To keep your APIs safe, you need strong authentication mechanisms, but the bigger challenge is ensuring you've got well-controlled authorization policies that you are testing rigorously and continuously to make sure they're free of logic flaws or loopholes.
Use Random Universally Unique Identifiers (UUIDs)
The next step is redefining how you approach the process of generating and managing IDs within your API ecosystem. Auto-incrementing IDs absolutely have to go.
As an alternative, use random IDs when creating and accessing APIs. These IDs, commonly referred to as UUIDs, are designed specifically to be difficult for cybercriminals or unauthorized users to guess.
UUIDs are made up of a combination of letters, numbers, and symbols that have no inherent meaning or pattern, making them virtually impossible to guess or reverse-engineer.
Using UUIDs minimizes the risk of malicious tampering, one of the root causes of BOLA vulnerabilities.
Laser-focus on Your Business Logic Layer
BOLA vulnerabilities are so tricky because they often lurk in the business logic layer of your APIs.
The implications? It means that BOLA vulnerabilities typically occur due to the flaws in the design of the legitimate functionalities of your APIs rather than bad agents using complex exploits to break into your systems.
That's why it's critical to meticulously test your business logic layer to spot vulnerabilities that are impossible to reliably address upon each release with vulnerability scanners.
“BOLA is already #1 on the OWASP API Security Top 10 list - and for good reasons. API providers do a great job at making sure that users are authenticated to the API, so they want to make sure that legitimate users have access. But the number one thing that's often overlooked is authorization, ensuring that user A can't access user’s B resources. And it's one thing to hide the resource IDs, but the important factor there is that user A should not be able to access, interact with, or alter user B's resources - at all.”
- Corey Ball, Cybersecurity Consulting Manager and Author of "Hacking APIs"
Implement the Zero-Trust Security Model
Enforcing the zero-trust security model is another step organizations typically take to protect APIs from BOLA vulnerabilities.
In a traditional security model, authorized and authenticated users are trusted by default.
However, in the zero-trust security model, all users must be authenticated and authorized before accessing any resources. Additionally, the authorized users are constantly monitored to prevent insider threats.
Based on this model, each API call must be authenticated and authorized before it can be executed. Once the user has been authenticated, the authorization mechanisms in place determine whether the user is allowed to access the requested resource.
If the user is not authorized, then the API call will not be executed, making it more difficult for attackers to exploit BOLA vulnerabilities.
Ensure Continuous API Security Testing
This is arguably the most effective way to protect APIs from BOLA vulnerabilities. However, here's the rub.
Traditional API security testing tools aren't reliable since vulnerability scanners don't take into account the unique architecture of your API while pen testing is impossible to scale to ensure full coverage with each update.
This is where APIsec comes into play.
APIsec is an industry-leading solution that leverages the power of AI to dissect your API and generate custom-tailored attack scenarios aimed at identifying business logic vulnerabilities.
APIsec is the only reliable way to automatically secure your API from BOLA vulnerabilities and, most importantly, business logic flaws while ensuring full coverage and eliminating human error.
Sounds too good to be true? Get in touch with our team today to get a free demo.
More Resources
The deploy gate is the last control point
The depth of a human. The coverage of a machine.
Start free and see a proven exploit against your own application, or get a walkthrough tailored to your stack.
