APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
- It's a simple IDOR (Insecure Direct Object Reference)
- That an API isn't checking a reource before you do something to it
- You should be keeping an eye out for any ID - numeric or UUID
- These are particularly common in RESTful APIs
- When you see an endpoint with an ID, try removing all the cookies and seeing if the endpoint still works
- If it doesn't try replacing the cookies with those of another user and seeing if it works or replacing the ID with something owned by another user
Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising system's ability to identify client/user, compromises API security overall.
- That an API should have some form of authentication but it doesn't
- That an API can easily generate authentication for other users
- API keys found via google dorking
- APIs wtich generate or use some form of token, without securing it
- Google dorking to find API keys (Github is great)
- Recon to find internal APIs which might take certain keys - this is gret to then test internal APIS and find even more bugs.
- Always test login systems, especially for password reset + token generation.
Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
- Information disclosure
- An API returns too much information, when it doesn't need to and that info can be a security risk - eg contains PII
- Always keep an eye out for any endpoint that returns a ton of stuff.
- Not always a bug, but worth investigating.
- API Enumeration or press buttons to find API endpoints that you wouldn't normally hit.
- If you see a lot of information being returned, ask yourself if that is a risk.
Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
- You can DoS an API because it doesn't limit the amount of requests you can do.
- More interestingly you can brute force information from an API.
- It can be difficult to spot - so just be aware that if an API doesn't return an error it might be vulnerable.
- The best way to find a bug that will pay out: Use it in another attack
- Eg: If an API requires an ID, lack of rate limiting will allow you to just keep testing an endpoint until one works
Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
- Permission IDOR
- You can do an admin action, even though you are a regular level user.
- Any complex permission hierarchy plus IDs
- You can use containers in Firefox to login to an admin account and a user account at the same time.
- Do admin actions, repeating each request and change the cookies to the regular users.
- Autorize can do this automatically.
Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
- That an API will accept additional parameters unintentionally and change them along side the intentional ones.
- So imagine an API endpoint that changes your username, if you gave it the right parameters it would also change other properties, eg your password.
- They are more common when an API is built on a framework - often the default setting.
- Another clue might be additional parameters with some default values.
- Pure recon. You should use tools to discover additional parameters in requests and see if anything changes.
- Eg: for a user try to change the username and check for additional parameters such as email or password - you may be able to bypass checks, eg confirm password.
Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
- Whoever is managing the API made some mistakes in configuring the server - eg by not updating it.
- Many different bugs with many different signs.
- But likely to be more common with smaller teams.
- Learn the common misconfiguration bugs and how to exploit them.
- CORS + CSRF = nice attack
Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
- That injection payloads eg SQL injection are not being sanitised by the API.
- So you can run potentially dangerous payloads via the API.
- Common for internal or not-for-puclic-use APIs where bugs might have been left in.
- Older applications
- Decide on the type of injection eg NoSQL, and look at potential payloads.
- I like PayloadAllTheThings
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
- That even though v1 of the API is broken and full of bugs, it's still up and connected to the same data source as v2.
- Anywhere you see versioning, you should check for higher/lower versions /api/v4.5/user
- Relies on a little bit of recon to find.
- But once you find it you should use it to find more bugs or bypass fixes.
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
- For the defending team: They need to know what parts of the API are being exploited and how.
- If they don't have logs, it's hard to stop the bad guys.
- This isn't a bug bounty bug, it's more of an issue on their side.
- One sign might be utter confusion when you send in a report because they had no ideat that an API existed.
- Not really a bug to report, but something to be aware of when you report.
- It can help up the impact when you do something super demanding without then noticing.
You should be vaguely familiar with them all, but I recommend reading on the bugs you're most interested in.
- Great for beginners: IDORs, Information exposure, improper asset management.
- Great if you like recon: Mass assignment, Information exposure, improper asset management.
- Don't bother looking: injection, insufficient logging.