Ladies and Gentlemen, let’s do some API hacking today. I will discuss some of the top 10 API bugs and where one can find them.
API:
API stands for Application Programming Interface. It provides a computer friendly method of interacting with a data source or backend logic.
1. API1: 2019 Broken Object Level Authorization
- API’s tend to expose endpoints that handle object identifiers, creating 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 form the user.
What does it mean?
- It’s a simple IDOR (Insecure Direct Object Reference). In this case an API isn’t checking that you own a resource before you do something to it.
What are the signs of this bug?
- You should be keeping an eye out for any ID — numeric or UUID. These are particularly common in RESTful APIs.
How can you find it?
- 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.
2. API2: 2019 Broken User Authentication
- 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 the client/user, compromises API security overall.
What does it mean?
- It means that an API should have some form of authentication but it doesn’t , i.e that an API can easily generate authentication for other users.
What are the signs of this bug?
- You will find some API keys via google dorking or APIs which generate or use some form of token, without much security.
How can you find it?
- Google Dorking to find API keys( Github )
- Recon to find internal APIs which might take certain API keys ( Security Trails, Github, shodan, spyse, binary edge, censys, intelx, spyse, urlscan, zoomeye, virustotal, chaos, dnsdb, etc). This is great to then test internal APIs and find even more bugs.
- Always test login systems, especially for password reset + token generation.
3. API3: 2019 Excessive Data Exposure
- 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.
What does it mean?
- An API returns too much information, when it doesn’t need to and that info can be a security risk. Example: Bugs that are classified as P1 or PII.
What are the signs of this bug?
- Always keep an eye out for any endpoint that returns a ton of stuff. It’s not always a bug, but always worth investigating.
How can you find it?
- While doing your API Enumeration, if you see a lot of information being returned, ask yourself if that is a leak. There are no pre-configured tools to find this bug, but solely depends on your patience.
4. API4: 2019 Lack of Resources & Rate Limiting
What does it mean?
- 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.
What are the signs of this bug?
- It can be very difficult to spot the bug but just be aware that if an API doesn’t return an error, it might be vulnerable.
How can you find it?
- The best way to attack using this technique, is to chain it with other bugs. i.e if an API requires an ID, lack of rate limiting will allow you to just keep testing an endpoint until one works.
5. API5: 2019 Broken Function Level Authorization
- 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 user’s resources and/or administrative functions.
What does it mean?
- You can do an admin action, even though you’re a regular level user.
What are the signs of this bug?
- Any complex permission hierarchy + ID’s.
How can you find it?
- You can use containers in Firefox to login to an admin account and user account at the same time.
- Execute some admin actions, repeat each request and change the cookies to the regular users.
6. API6: 2019 Mass Assignment
- 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 they are not supposed to.
What does it mean?
- It means 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 might also change other parameters. Ex: Your password, addresses, etc.
What are the signs of this bug?
- They are more common when an API is built on a framework — Often with the default settings or some additional parameters with some default values.
How can you find it?
- Not gonna lie dude. It depends upon your recon i.e availability of various wordlists, right set of tools, automation + manual checking of various parameters.
- This is mostly a hit & trial method.
7. API7: 2019 Security Misconfiguration
- 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.
What does it mean?
- Whoever is managing the API made some mistakes in configuring the server. Ex: By not updating the servers.
How can you find it?
- Learn the common misconfiguration bugs and how to exploit them. There is no pre-configured path to find this issue.
8. API8: 2019 Injection
- 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.
What does it mean?
- The injection payloads e.g SQL Injection are not being sanitised by the API, i.e you can run potentially dangerous payloads via the API.
How can you find it?
- You must decide on the type of injection; e.g NoSQL, and look at various ways of uploading it in applications or websites.
→ Github Links:
* https://github.com/swisskyrepo/PayloadsAllTheThings
* https://github.com/R0B1NL1N/PayloadsAllTheThings
* https://github.com/hakluke/weaponised-XSS-payloads
Tips:
You should also check for this profile Thexssrat. The explanations are simpler, and up-to-date.
9. API9: 2019 Improper Assets Management
- 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.
What does it mean?
- 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.
What are the signs of this bug?
- If you see anywhere about versioning, you should check for higher/lower versions. Example: <ENDPOINT>/api/v4.5/user.
How can you find it?
- It relies on a little bit of recon skills, but if you do find it, you should use it to find more bugs or bypass fixes.
- Depends on:
1. Your patience.
2. Time allocated to each subdomain or domain.
Tips:
- Gather all JS files and scrape the files for endpoints using JSScanner or tools proposed by TomNomNom.
- Or try to write your own tools and scripts for automation.
Preferred Languages: Go or Bash.
10. API10: 2019 Insufficient Logging & Monitoring
- 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.
What does it mean?
- For the defending team: They need to know what parts of their API are being exploited and how.
- If they don’t have logs, it’s hard to stop the bad guys.
What are the signs of this bug?
- This isn’t really a bug bounty bug, it’s more of an issue on their side.
- Do me a favour. Don’t send any reports to the security team.
How can you find it?
- If you do find the bug, try to chain bugs to make it more presentable or should I say to increase impact of the vulnerability you’re reporting.
With Love,
Aaryan
