Microservices — OWASP Security Threats
By: Lal Verma
Tags: Microservices, Security, Software Engineering, Owasp, Software Architecture

Microservices — OWASP Security Threats

In this article, I am capturing the top ten security threats for microservices based on OWASP — Top Ten. We will look into the definition, example scenarios, and solutions for each of these threats.

Photo by Matthew Henry on Unsplash

Overview

Microservices Architecture has changed the way applications used to be built, developed, tested, deployed, monitored, and secured. We do not have a single entry point to the system now. The monolith is broken into multiple microservices. In this article, we are going to address the top ten security threats for microservices based on OWASP — API Security Top Ten.

Open Web Application Security Project (OWASP) is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security. OWASP has many projects, web-application security being the most popular. My focus lies with their other project API Security, which deals with the vulnerabilities and security risks of Application Programming Interfaces (APIs). This project has a close resemblance to the nature of microservices.

Here are the top ten security threats listed in the OWASP API Security project. We will be going through each of these risks and understand them along with the solutions. Each of these risks can be browsed independently if you like.

Broken Object Level Authorization

OWASP Definition

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 input from the user.

Example Scenario

A user profile is available at http://our-ecommerce-store.com/user/profile/${user-id} . If the API is assuming the request is coming from an authorized user and not validating the user details against the user-id , an attacker can access the details of any user by using the same URL. The attacker just needs to be aware of the user identifier — user-id .

Solutions

Implement Object-level authorization at the service/API layer . These are fine-grained authorizations and should be handled in the code. For e.g. return the user object only if the user is authorized for the object.

at the service/API layer These are fine-grained authorizations and should be handled in the code. For e.g. return the user object only if the user is authorized for the object. Generate Random Identifiers to make it difficult for the attacker to guess the identifier values. Avoid generators like “auto sequence”.

to make it difficult for the attacker to guess the identifier values. Avoid generators like “auto sequence”. Implement Edge Level Authorization which should be able to authorize the API requests based on the user scopes/role/group (open id/OAuth attributes).

which should be able to authorize the API requests based on the user scopes/role/group (open id/OAuth attributes). Make “authorization checks” part of the CI/CD process to validate the authorization mechanism of our services periodically and make it a part of build and release cycles.

Broken Authentication

OWASP Definition

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 a system’s ability to identify the client/user, compromises API security overall

Example Scenarios

Brute force attack happens when the attacker tries to break into an account by trying multiple passwords. He/She can automate these attacks based on a dictionary or other source where multiple combinations are stored. The trick can be applied at login/reset password flows.

Credential stuffing is a well-known attack where the attacker acquires the list of usernames and passwords from a data breach of an enterprise (or a website for e.g. sony’s data breach). The attacker then checks each of these accounts in the list against the targetted websites.

The attacker sends spam mail and the user clicks on the malicious link. The attacker gets hold of the user token and tries to access/update his personal data.

The user logs out of the application but the access token is still active. The attacker gets hold of the token and calls the API directly.

Solutions

All the network calls should be accessible through HTTPS only — client application to service, service-service, API gateway-service, client — API gateway, etc.

— client application to service, service-service, API gateway-service, client — API gateway, etc. Use API Gateway to implement edge security and provide a single entry point to the system. Services should not be exposed directly to the client APIs. They should be restricted within the firewall boundaries. All the service calls must route through this.

Use OpenId & OAuth 2.0 authentication and authorization frameworks .

. Use “mTLS” or JWT for all service to service communications .

. Encrypt the passwords , security questions/answers, and other sensitive profile information in the storage/database.

, security questions/answers, and other sensitive profile information in the storage/database. If you are saving the tokens in a cookie, use the secure cookie flag . This instructs the browser to only send them over encrypted HTTPS connections.

. This instructs the browser to only send them over encrypted HTTPS connections. Do not include any of the keys/credentials in your source code . CI/CD should enable the right credentials at the deployment time.

. CI/CD should enable the right credentials at the deployment time. Validate the security token based on “issuer”, “audience”, “expiry”, “scope” and other expected parameters.

based on “issuer”, “audience”, “expiry”, “scope” and other expected parameters. Implement weak-password checks . Enforce the use of strong passwords based on multiple characters, minimum password length, etc.

. Enforce the use of strong passwords based on multiple characters, minimum password length, etc. Similar to the passwords, ensure the security questions and answers are also strong and not easy to guess.

Use multi-factor authentication to prevent automated login attempts against accounts.

to prevent automated login attempts against accounts. Use an effective CAPTCHA to prevent automated login attempts against accounts.

to prevent automated login attempts against accounts. Implement “Rate Limiting” to restrict the number of requests from a particular IP address. This can be implemented at the API Gateway layer.

to restrict the number of requests from a particular IP address. This can be implemented at the API Gateway layer. Use the option of security question or memorable word to protect against automated attacks. Furthermore, security questions are often weak and have predictable answers, so they must be carefully chosen.

Use the Account lockout strategy to prevent any more login attempts for a period after a certain number of failed logins.

Excessive Data Exposure

OWASP Definition

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.

Example Scenario

The GET API of Product Review Service provides reviews from various consumers. The review object also has a user(author) object attached, which contains sensitive profile information. An attacker can use this information to hack the user(author) account.

Solutions

Only return the data which is required by the client interface/service.

by the client interface/service. Do not rely on the client APIs to filter the data . Use request context and user profile to prepare the response payload.

. Use request context and user profile to prepare the response payload. Handle the NoSQL document data carefully . Quite often the document represents the data entity with its related entities as well. If you are keeping the relational data in one single entity, you must craft the response carefully.

. Quite often the document represents the data entity with its related entities as well. If you are keeping the relational data in one single entity, you must craft the response carefully. Avoid the technology references in your HTML pages .

. Do not return the error responses directly you received from the internal components/libraries/services, directly to the client. Sometimes this may contain the stack-traces, which can directly expose the technology and other implementation details.

you received from the internal components/libraries/services, directly to the client. Sometimes this may contain the stack-traces, which can directly expose the technology and other implementation details. Use standardized error codes and messages which are agreed upon by both the consumer and producer services.

Lack of Resources & Rate Limiting

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.

Example Scenarios

User bombards the API with millions of requests in a short span of time, forcing services to reach its resource limits and leads to DDOS.

Product Catalog GET API returns the list of products but it relies on client API (implementing pagination) to send the page limit. An attacker can set the limit to a large number which can push the service to return a huge payload. Service consumes all of its networks and compute resources for one request and becomes unavailable for other requests.

User Profile API accepts the profile pic but does not limit the size of it. An attacker can send a large file and again bring down the service performance.

Solutions

Limit the “request payload size” for the service. If the parameter is a string, set the maximum length. If the parameter is an array set the maximum number of elements. If the parameter is of type media or document set the maximum size.

for the service. If the parameter is a string, set the maximum length. If the parameter is an array set the maximum number of elements. If the parameter is of type media or document set the maximum size. Limit the “number of request rate per client ” based on a specific user, IP address, or the calling service.

” based on a specific user, IP address, or the calling service. Limit the “number of records per response ” at the service side. This limit is independent of what the limit is coming from the client/user end.

at the service side. This limit is independent of what the limit is coming from the client/user end. Limit the Memory — The limit on memory cannot be set at the code level. If you are using containers to deploy your services, this is piece of cake though. Docker provides easy options to do it. You can find more details on this topic on the docker webpage.

— The limit on memory cannot be set at the code level. If you are using containers to deploy your services, this is piece of cake though. Docker provides easy options to do it. You can find more details on this topic on the docker webpage. Limit the CPU cycles — Similar to the memory, this limit can also be set through Docker. You can define the “maximum CPU” cycles (of a host) a particular container can consume. For more details on this, you can visit the docker webpage.

Broken Function Level Authorization

OWASP Definition

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.

Example Scenario

Product Catalog API has GET, PUT, POST & DELETE APIs. The registered user could just be a consumer. He can still access PUT/POST/DELETE APIs because the API only checked if the user is authenticated or not. It did not check if the user is authorized based on his role/group etc.

Solutions

Your security policies should deny all access by default . This way you will be able to explicitly define the roles and group access for specific APIs.

. This way you will be able to explicitly define the roles and group access for specific APIs. You should use OAUTH scopes(read, write), OPEN ID attributes (role, group) to define the access to APIs .

. Use Edge Security to implement such coarse-grained authorizations. If the APIs are based on the REST model it will be easier to implement the security policies. For e.g. API Gateway can restrict the access of POST/PUT/DELETE APIs only to the admin role.

to implement such coarse-grained authorizations. If the APIs are based on the REST model it will be easier to implement the security policies. For e.g. API Gateway can restrict the access of POST/PUT/DELETE APIs only to the admin role. Take extra care to implement permissions and grants for administrative operations . The less complex the user hierarchy, the easier it is to configure the access/restrictions.

. The less complex the user hierarchy, the easier it is to configure the access/restrictions. Do not be content by just limiting the user actions at the UI (based on user role/group). It is not good enough until the restrictions are in place at the API layer.

Secure your services based on mTLS (service identity authorization), JWT (secure user context)

Mass Assignment

OWASP Definition

Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads 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.

Example Scenario

Our e-commerce store provides the user to update his/her profile. The endpoint is based on the PUT API at /profile/test-user . Attacker updates the profile with the following upload where he/she passes an extra attribute called “bonus_points”. If bonus_points is an actual parameter of the internal object and no check is placed, the attacker will be able to update his “bonus points” with no payments.

{user_name:"abc",age:24,bonus_points:"10000"}

Solutions

If possible, avoid using 3rd party libraries/APIs which automatically bind the input payload to the internal objects like POJOs.

the input payload to the internal objects like POJOs. Do not pass the whole POJO to the database/storage directly . Instead, choose only the properties that should be updated by the user.

. Instead, choose only the properties that should be updated by the user. You should use the built-in features to blacklist properties that should not be updated in the request.

that should not be updated in the request. If possible, define the input payload schemas explicitly for each of the API endpoints.

Security Misconfigurations

OWASP Definition

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.

Example Scenarios

TLS is configured for Server/Services/API Gateway but they can still be accessed through plain HTTP.

Database Server is running with its default configuration where authentication is disabled by default.

Docker is running with default user — root.

CORS misconfiguration in services, for instance — *.*, localhost.

Solutions

A repeatable hardening process should be applied to each technology and platform in the ecosystem including microservices, cloud services, databases, files/storage, open id/OAuth servers, application servers, container/container orchestration services, service mesh frameworks, etc.

to each technology and platform in the ecosystem including microservices, cloud services, databases, files/storage, open id/OAuth servers, application servers, container/container orchestration services, service mesh frameworks, etc. Default configurations should be well inspected and updated as needed.

and updated as needed. All network communications should be secured including client-APIs, API interactions, and media access, based on TLS, Cors policies, firewall configuration, etc.

including client-APIs, API interactions, and media access, based on TLS, Cors policies, firewall configuration, etc. A task to review and update configurations across the entire API stack should be in place enabling the continuous deployment of services. Ensure continuous & automated assessment of the configurations.

across the entire API stack should be in place enabling the continuous deployment of services. Ensure continuous & automated assessment of the configurations. To prevent exception traces and other valuable information from being sent back to attackers, if applicable, define and enforce all API response payload schemas including error responses.

including error responses. Ensure API can only be accessed by the specified HTTP verbs . All other HTTP verbs should be disabled (e.g. HEAD ).

. All other HTTP verbs should be disabled (e.g. ). APIs expecting to be accessed from browser-based clients (e.g., WebApp front-end) should implement a proper Cross-Origin Resource Sharing (CORS) policy.

If interested in securing your deployment platforms like Docker, Kubernetes, check out the following article

Injection

OWASP Definition

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.

Example Scenarios

Exploiting Parameter Evaluations — Let’s assume that we have an Order Management Service which is built on Node.js and exposed as a REST API. If you access the order details page with the URL — http://our-ecommerce-store/order?orderId=test-order-id , the query parser will convert the parameter string to a query object. If I am using the parameter directly into my service to fetch order details, an attacker can manipulate the parameter value with something like this [%24ne=] . The MongoDB query will find the orders where orderId is not equal to blank

db.collection('orders').find({

"orderId": {$ne:""}

});

Exploiting Javascript Expressions — MongoDB provides the option of $where clause where you can pass the javascript expressions. The attacker can pass the value of orderId as ‘test-order-123’; sleep(5000) . This will halt the system for 5 seconds.

db.collection('orders').find({

$where:

return (this.orderId == req.query.orderId)

}

});

Solutions

Sanitizing Input Parameters — We must sanitize our input parameters before we use them in database queries. You can use the “mongo-sanitize” or “mongoose” node libraries to sanitize the input values. If you can’t find a library for your environment, you can convert user inputs to the expected data types, to reduce risk.

— We must sanitize our input parameters before we use them in database queries. You can use the “mongo-sanitize” or “mongoose” node libraries to sanitize the input values. If you can’t find a library for your environment, you can convert user inputs to the expected data types, to reduce risk. Disabling Javascript Executions — In the case of MongoDB, most of the query features are available without using any javascript expression. This is an optional feature and must be used when you run out of other options. You can disable all server-side execution of JavaScript if you do not use it.

In the case of MongoDB, most of the query features are available without using any javascript expression. This is an optional feature and must be used when you run out of other options. You can disable all server-side execution of JavaScript if you do not use it. Use the Least Privilege — You can define multiple service accounts or keys to access the database. All the different operations including READ, CREATE/UPDATE, DETELE can have different access keys.

— You can define multiple service accounts or keys to access the database. All the different operations including READ, CREATE/UPDATE, DETELE can have different access keys. Use Latest Versions — As already said, the NoSQL technologies are new. Apply the software and security updates regularly.

As already said, the NoSQL technologies are new. Apply the software and security updates regularly. Avoid Excessive Data Exposure- Almost all the time, the attacker is aware of the deployed technology stack including application server, driver, frameworks, and database in such attacks. We should avoid exposing technology details through our responses, HTML pages, etc.

Improper Asset Management

OWASP Definition

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.

Example Scenarios

Our product catalog API is updated and fixed the security gaps. API V2 is available now. But the old version is still running, unprotected.

Solutions

When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version.

Document the contract and conditions for each of the APIs. Make API documentation available to those authorized to use the API.

Mark the APIs/functions deprecated if they are about to retire.

Retired APIs should be moved out.

Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version.

Insufficient Logging and Monitoring

OWASP Definition

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.

Example Scenarios

Many user logins are compromised through brute force attacks. Due to insufficient logging, it took a few days for the operation team to notice.

An attacker is able to exploit the weakness of our Product Catalog API and successfully executed DOS (denial of service) attacks. Our Monitoring System failed to generate alerts on time. We got to know of the unavailability of the services based on customer queries.

Solutions