Halodoc is a fastest-growing technology health-tech company, delivering a suite of connected health services including medical delivery services, and licensed medical laboratory services across Indonesia. Although we maintain a large number of sensitive medical data of our customers, we also make diligent efforts to minimize product vulnerabilities.
To ensure the security of web APIs from data breach, we strongly follow the security guidelines right from the product designing phase, implement for security including all common kinds of vulnerabilities, and very importantly the intelligent security testing with a comprehensive test case coverage. This results in high confidence before we ship the product.
This blog aims to help you identify the API vulnerabilities before the product is shipped and the most common challenges while security testing of API. A thorough explanation of 'OWASP API security top 10 report' will also be covered .
Why API security is important ?
APIs are the means by which an enterprise’s most valuable assets are accessed to the network's entry point. These are the calls to the backend server to provide the functions of an application. In 2021, 83% of all web traffic communication is suspected through APIs, and by 2022 APIs will be the #1 attack vector as per the API vulnerability report at apisecurity.io. This large exposure of API expands the larger threat's surface. That's when the API's quality and security are highlighted.
How does Halodoc secure APIs?
Prevention is better than correction, when it comes to security. Any data breach fix after release costs around 5X than it is in the testing phase. Since we understand that web APIs are one of the leading vectors of security attacks, maintaining the security of APIs is an essential part of any release cycle in Halodoc. Some of the very common security coverage includes - Restricted malicious URLs in upload, SafeString implementation, CSRF token implementation, redirection of whitelisted URLs only, Rate Limiting against brute force attack, and the list goes on. Alerting, monitoring and immediate countering the vulnerability reports are the additional mitigation actions in Halodoc.
Challenges while security testing
A test engineer must think like an attacker to protect our systems from security threats. Think about what the adversary is exposed to, attempt to, see if those results can be reproduced. Think outside the box while creating test data to achieve what quality we want.
1. What to cover
The very first challenge for any backend test engineer is to think about coverage. To overcome this issue you should first identify flaws and vulnerabilities in your APIs, do a vulnerability assessment to analyze the security of a basic secure system, score their risk, and prepare test data accordingly. Also, identify 'What security team gonna cover' and ‘what's developers common sense’.
2. When to stop
"Testing can never be finished but, we cannot test all the time". OWASP launched a separate project dedicated purely to API security, which focuses specifically on the top 10 vulnerabilities in APIs. It covers the emergence of API-specific issues that need to be on the security radar. I will explain each of them in detail later in this blog.
3. How to test
APIs security testing can be performed using both manual and automation testing methodologies by estimating security standards. Test scenarios with a set of relevant test data based on vulnerability outlines play a significant role in decision making.
API safety testing check list to mitigate vulnerability attacks
- Broken Object-Level Authorisation (BOLA)
- Broken Authentication
- Excessive Data Exposure
- Lack of Resources And Rate Limiting
- Broken Function Level Authorisation
- Mass Assignment
- Security Misconfiguration
- Improper Asset Management
- Insufficient Logging
1. Broken Object-Level Authorisation (BOLA)
Improper authorization allows access to unauthorized requests. Providing fine-grained access to resources can often lead to an explosion.
Example: UBER (2019) - Personally identifiable information records of riders, drivers, and partners were accessible by hackers.
- To prevent it from hitting your API, check authorization each time there is an API call to the database.
- Validate authorization for user policies & hierarchy.
- Guess the random ID of the object, though it doesn’t always work, sometimes it does.
- One of the most efficient ways is to perform the ‘Session Label Swapping’ technique like changing the session label of user #1 to the session label of user #2.
- Wrap the ID with an array.
- Wrap the ID with a JSON object.
2. Broken Authentication
Incorrectly implemented functions related to authentication and session management, allow attackers to compromise passwords, keys, session tokens, or to exploit other implementation flaws.
- Validate the scope of parameters in different apps.
- Authorization should not just be implemented for users but for applications as well.
- Short-lived tokens.
- Stricter rate limiting.
3. Excessive Data Exposure
Sometimes excessive data exposure is intentional to give the user a greater understanding of the application and how it functions. The same information can be used for malicious purposes by the trackers. The API should only include what the client legitimately needs.
Example: UBER FULL ACCOUNT TAKEOVER (2019) - Full account information is returned by API, when only a few fields are used by the UI. This includes the mobile token used to login onto the account.
- APIs should not give more data to the clients than what they really need.
- Error responses must not reveal any sensitive information.
- Unauthenticated calls should never provide an authentication token in response.
4. Lack Of Resources & Rate Limiting
Attackers can overload the number of requests that come to your application and causes an excessive amount of API calls or payload sizes.
Example: INSTAGRAM (2019) - The vulnerability was in the API that Instagram exposes for password resets in its mobile app.
- Set up a rate limiter for the APIs based on the number of requests originating from a specific source (ex, source IP address).
- Validate pagination to prevent from sending millions of results causing extraneous network traffic which can slow down / fail the system at some point.
- Denial of Service (DoS) should be implemented to prevent authentication flaws like brute force attacks.
- Review user roles and their membership.
5. Broken Function Level Authorisation
The API relies on the client to use user-level or admin-level APIs as appropriate. Attackers figure out the hidden admin API methods and invoke them directly. It can be a matter of knowing the URL, or using a different verb or a parameter:
Example: RUSSIAN GOVT. OFFICIAL’S DATA BREACH (2021): Attackers got in through the API of the mass email system, Mailgun and accessed all data.
- Only allow operations to users belonging to the appropriate group or role.
- Flawed / default scope validation of parameters in different apps.
- Properly design and test authorization.
- Validate OAuth access tokens are not reusable.
- Make sure all privileges are not provided to a user by default.
6. Mass Assignment
An API may represent a data structure in an internal database. Attackers can try to guess object properties to provide additional object properties in their requests, they can read the documentation, or can check out API endpoints for clues to find the openings. Further, they can modify the properties, they are not supposed to.
- Check for No automatically bound of incoming external data.
- All the expected parameters & payloads should be explicitly defined.
- For object schemas, only readOnly should be set to True for all the properties that can be retrieved through APIs but should never be modified.
- The API should not work with services other than the one defined for the same.
7. Security Misconfiguration
This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, misconfigured HTTP headers, and verbose error messages containing sensitive information.
Example: NPM MALICIOUS CODE
- Not only must all frameworks, libraries, and applications, should be securely configured, but they must be patched/upgraded in a timely fashion.
- Validate restricted administrative access.
- Validate unnecessary features are disabled.
Injection flaws, such as SQL, NoSQL, etc injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Example: COMMAND INJECTION ATTACK - In this particular attack, server executed commands written in ONGL language when a Content-Type validation error is raised.
- Define, limit, and enforce API outputs to prevent data leaks.
- Validate all incoming data is filtered, sanitized, and only accept what is expected.
- Never trust your API consumers, even if internal.
9. Improper Asset Management
The attacker finds non-production versions of the API: such as staging, testing, beta, or earlier versions - that are not well protected, and uses those to launch the attack.
Example: JUST DIAL(2019) - JustDial leaked the personal data of all its 100 million users due to an unprotected API.
- Validate limited access to production data.
- Make sure additional external controls like firewall are implemented.
- Backward security fixes & old versions should be properly retired.
- Validate strict authentication, redirects, CORS, etc.
10. Insufficient Logging & Monitoring
When something bad happens, you should be able to identify and track it through the captured logs. The inclusion of sensitive information in log files is a security breach and weakness of the system.
Example: 7-ELEVEN, JAPAN (2019) - The attackers took over about 900 user accounts and spent their money before the vulnerability was identified.
- Check failed attempts, access denied, and input validation failure logs.
- Make sure logs are highly sensitive and do not print sensitive information.
- Logs have enough details to identify attackers.
- An adequate encryption check for sensitive information.
- Check logs integration with some monitoring tools.
We finished off looking at risk and the default technical impact of a specific weakness or exposure. We also came to the conclusion that data breaches can easily be weaponized. As a result, it's crucial that we make sure our tests are on the security radar and making progress.
- Security design - constantly consider design principles such as least privilege and non-bypassability.
- Implement for security - counter common kinds of mistakes. Simply countering common kinds of vulnerabilities is not enough to create a secure system but it is a big step forward. This will also help you become aware of other kinds of vulnerabilities.
- Verify - remember, all APIs are open APIs. Use self-hacking to detect problems. For each functional test, create at least 10 negative tests, and hammer your APIs with bad tokens, bad data, and bad users.
Security is a process - a journey - and not a fixed destination.
We hope you feel far more prepared to counter attackers and to identify vulnerabilities before the product is shipped.
Scalability, reliability and maintainability are the three pillars that govern what we build at Halodoc Tech. We are actively looking for engineers at all levels and if solving hard problems with challenging requirements is your forte, please reach out to us with your resumé at firstname.lastname@example.org.
Halodoc is the number 1 all around Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke. We connect 20,000+ doctors with patients in need through our Tele-consultation service. We partner with 3500+ pharmacies in 100+ cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services, and to top it off we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application. We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, GoJek, Astra, Temasek and many more. We recently closed our Series C round and In total have raised around USD$180 million for our mission. Our team works tirelessly to make sure that we create the best healthcare solution personalised for all of our patient's needs, and are continuously on a path to simplify healthcare for Indonesia.