devopsy.kinsta.cloud

Author: Justin Boyer

  • Use the OWASP API Top 10 to Secure Your APIs

    Use the OWASP API Top 10 to Secure Your APIs

    The tools, languages, platforms, and methods used to build applications have changed drastically over the past decade. Application security practices have to change with them; otherwise, security professionals will be playing constant catch-up with attackers and cybercriminals.

    What Is the OWASP API Top 10?

    The increase of microservices and application programming interfaces (APIs) has given rise to a new set of threats against applications. The OWASP API Top 10 documents the risks associated with API development.

    Here are the vulnerabilities highlighted in the most recent OWASP API Top 10:

    1. Broken Object Level Authorization (BOLA)
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources and Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging and Monitoring

    Why Is the OWASP API Top 10 Necessary?

    Large monoliths are giving way to small, nimble microservices. Kubernetes, containers, cloud-native architectures, and API gateways are the new hotness. This shift has also led to new threats.

    Let’s take a look at the differences between traditional web development and API development.

    Authentication and Authorization Look Completely Different

    Three out of ten risks in the API Top 10, including the first two, deal with authentication and authorization issues. These critical security functions look differently with APIs than they do with more traditional web applications.

    In a typical web app, the user logs in and the server grants a session cookie. The browser stores the cookie and passes it to the server with every request, removing the need to re-authenticate. All of the user’s permissions are tied to the session ID.

    APIs are made of several mini web apps all deployed on separate servers, each with its own data store. Creating a session in one server doesn’t matter much. The server receiving the next request won’t know anything about the session stored at the first server.

    This complexity gave rise to the OAuth and OpenID Connect specifications. These specs outline authentication (Open ID) and authorization (OAuth) for distributed systems. Using these techniques correctly helps to keep microservices and APIs safe.

    But even though authentication and authorization have changed for APIs, another aspect of them introduces a new big player in API risks: business logic errors.

    APIs Talk Too Much

    Traditional web applications expose one endpoint, and one executable running on the server contains all business logic. An attacker will have a difficult time mapping out all of the internal business logic of an application. With so much trial and error, it’s easier to go after vulnerabilities based on inputs, such as XSS or SQL Injection.

    On the other hand, breaking an application into microservices, each with its own API endpoint, by default exposes much of the business logic to the outside world. You can watch your browser’s connections to see the individual pieces of the application as a whole. And most of the time, the public interface reveals the essential parameters and unique identifiers of sensitive data objects.

    BOLA is an excellent example of this phenomenon. BOLA occurs when an attacker changes the resource ID passed into an API to retrieve someone else’s records.

    Imagine a medical application that holds sensitive documents. You can view your documents in PDF form. Since APIs are used to serve up your data, the client app passes an ID through the URL. You accidentally (because we know you’d never do this on purpose) transpose the numbers in the URL. All of a sudden, another person’s medical information stares back at you. You’ve discovered a BOLA vulnerability.

    Another example of APIs talking too much is with claims-based authentication. Typically, JSON web tokens (JWT, pronounced “jawt”) are used to send the current user’s permissions, referred to as “claims.” These tokens are easily decoded and updated.

    Imagine receiving a JWT using OAuth and decoding it. You notice that one of the attributes on the token is “admin: false.” Now you know how the application determines your permissions. You change the attribute to “admin: true” and send it back to the application with the next request. If the API doesn’t follow the correct token signing and verification procedures, you’ve now become an administrator and can gain access to all sorts of goodies.

    Make sure your APIs aren’t leaking too much information. Be aware of what your API’s clients see and determine the risks and mitigation of each piece of data.

    “Loose lips sink ships” was a famous security warning during World War II. In today’s world, loose data sinks APIs.

    Microservices and APIs Are (Too) Easy to Create and Deploy

    New development methodologies come with cultural changes within organizations. Developer autonomy and delivery speed are emphasized, leading to many development teams deciding how to implement APIs and when and where to deploy them.

    These methods lead to greater flexibility, agility, and scalability but could also create  API proliferation and increased risk. Number nine on the API Top 10 is Improper Assets Management. Not knowing where all of your APIs are and what they do can lead to serious application vulnerabilities.

    For example, in creating and deploying a new version of an API, an endpoint running the old version could still exist. Should the old version contain a security vulnerability, attackers could exploit it without your knowledge. Building an inventory using API discovery techniques allows organizations to find these endpoints and shut them down properly.

    Businesses need to be agile and responsive. But they must also be aware of the side effects these strategies create and design processes to keep things under control.

    If You’re Building APIs, Don’t Forget the API Top 10

    Building microservices and APIs is distinct from building traditional web applications. Differences in environments, frameworks, and development techniques solve some problems while introducing new ones.

    Get familiar with the OWASP API Top 10 and use it to check your applications. Add it to the regular security checkpoints you already have. Then you’ll be confident your APIs are safe and secure.

    Traceable Defense AI helps protect against the OWASP API Top 10. View a recorded demo to see it in action.

  • Secure Kubernetes Architecture: Six Factors Essential to Success

    Secure Kubernetes Architecture: Six Factors Essential to Success

    Kubernetes has become the go-to container orchestration tool for businesses.

    Check out these telling stats [source: Enterpriser’s Project]:

    • 84% of companies are using containers in production.
    • Of those, 78% are using Kubernetes to manage their containers.
    • 69% of companies have found security holes due to misconfiguration of their Kubernetes environment.

    Your Kubernetes architecture is like a large house with container “tenants” living inside it. You’ll need to build it with care to make sure it’s a safe and happy place to live.

    Here are six essential factors to get right when planning (or auditing) your Kubernetes architecture.

    Setting the Foundation: Underlying Platform and Control Plane Configuration

    The foundation of a house is a critical first step. A weak foundation leads to cracks over time.

    Similarly, where you install Kubernetes is your first choice. There are several options available, each with pros and cons.

    Kubernetes is a cloud-native tool. Therefore, it makes sense to install it on the cloud. There are two cloud deployment options: Infrastructure as a Service (IAAS) or Platform as a Service (PAAS).

    An IAAS installation involves creating a series of virtual machines in the cloud (for instance, using Amazon EC2) and installing Kubernetes on those machines. You’ll be responsible for updates and configuration of the Kubernetes installation.

    On the other hand, all major cloud providers offer managed Kubernetes services. This deployment model allows you to use Kubernetes without having to handle the infrastructure.

    Even though Kubernetes was made for the cloud, you don’t have to install it in the cloud. An on-prem installation is an option, with many companies choosing to use their virtualization infrastructure to host Kubernetes.

    You’ll find a quick summary of the pros and cons of each choice below.
    ‍

    Your decision depends on three factors:

    • The skillset of your team
    • Your need for control and flexibility
    • Your company’s goals

    Control Plane Configuration

    The Kubernetes Control Plane consists of the services run on the Master node. The cluster store, scheduler, controller manager, and API server combine to create the control plane.

    Plan your control plane security well. If an attacker gains access to your control plane, they’ll be able to control your entire Kubernetes cluster. Use SSH or a VPN / VPC to connect to and use the control plane.

    If you’re using a managed service from a cloud provider, protect your API keys and credentials. Don’t ever store them in a source control system. Losing your API keys would lead to a complete takeover of your cloud infrastructure, not only your Kubernetes installation.

    Finding Good Tenants: Container Security and Composition Analysis

    The wrong tenants can destroy your house. Similarly, dangerous containers can bring down your Kubernetes environment.

    Make sure any containers you bring in from the outside are vetted and configured correctly. Only use trusted registries, such as Docker Hub or Quay.io.

    Finally, scan your containers before using them. You can use open-source container scanners to find vulnerabilities and malware. You can integrate most scanners into your CI/CD pipeline.

    Plan Your Rooms Wisely: Kubernetes Cluster Partitioning

    The rooms in your house each have a different name and purpose. You don’t keep a stove inside your bedroom or a bed in the kitchen. You give tenants private rooms while allowing them to share common areas, such as the kitchen.

    In Kubernetes, namespaces allow you to separate various applications within the same cluster logically. If the cluster is your house, each namespace is a separate room within it.

    Give namespaces to each application within your cluster. This practice produces three benefits:

    • Logically separates applications and environments (Development, Staging, Production)
    • Allows for robust Role-Based Access Control (RBAC)
    • Allows for network partitioning for added security within the cluster

    Kubernetes RBAC Primer

    You can check out the Kubernetes docs for comprehensive explanations of RBAC within Kubernetes. But here’s a quick primer for those who don’t have the time to read it now.

    Kubernetes has Roles and ClusterRoles. They contain rules that represent a set of permissions. There are no “deny” rules, so you have to know what access is necessary.

    Each Role is scoped to a specific namespace. ClusterRoles, on the other hand, have no namespace. In Kubernetes, an object can only be namespaced or not; it can’t be both. Therefore it’s necessary to have two resources, one for each scenario.

    Use Roles to create permissions tied to a specific application. Use ClusterRoles for access to cluster-scoped resources or resources used by multiple namespaces.

    RoleBinding and ClusterRoleBinding is the act of assigning permissions to a specific user. A RoleBinding grants permissions within a single namespace while a ClusterRoleBinding grants access cluster-wide.

    For example, assigning the “pod-reader” Role to the user “jane” in the “default” namespace allows “jane” to read pods in the “default” namespace.

    Roles define a set of permissions. Then users, groups, or service accounts (collectively called “subjects”) are assigned roles to grant access to specific resources within the cluster.

    Define network partitioning and access control appropriate for the business’s needs before deploying any application into your cluster.

    Watch Your Wiring: Inter-Pod Communications

    Shoddy wiring is more than an inconvenience. It can lead to damaging fires or even destroy the entire house.

    Similarly, poor inter-pod communications can bring your Kubernetes cluster grinding to a halt.

    A Kubernetes environment is a small network ecosystem. The same network topologies, protocols, and policies govern pod-to-pod communication as those you’d find in any corporate network.

    A full discussion of Kubernetes networking is beyond the scope of this article. You can read up on it using the Kubernetes networking documentation. But here are some quick pointers.

    You can use Service Topology to define how traffic flows to and from a particular service. For example, a service can specify that traffic should be routed to endpoints on the same node as the client.

    Service Topology is useful in the public cloud. You can use it to keep a service’s traffic in a particular availability zone or region to reduce latency.

    Another useful networking tool is NetworkPolicies. These application-level constructs specify how a pod is allowed to communicate with other entities. This feature is especially useful when you want to control network traffic using IP addresses or ports.

    Finally, you need to have a robust authentication and authorization strategy. We recommend using a service mesh to simplify load balancing, service discovery, encryption, and authentication. For example, service meshes include support for OAuth, which makes service authorization much easier to manage.

    Secure the Front Door: Ingress Architecture

    There’s no point in building a secure home and then leaving the front door unlocked. You don’t want to do that with your Kubernetes cluster either.

    In Kubernetes, Ingress exposes HTTP and HTTPS routes from outside the cluster to your services within it. Ingress is your environment’s “front door.”

    [source: Kubernetes docs]

    Carefully consider which server to use in your Ingress architecture. NGINX is a tried and true web server with all of the security features necessary to protect your services. NGINX now offers an Ingress Controller for cloud-native Kubernetes environments.

    However, you may want to give Envoy a look. It’s an open-source edge and service proxy built by Lyft specifically for cloud-native applications. It tackles the common observability and network debugging issues common in a microservice architecture. Envoy can also serve as a service mesh.

    As the “front door” to your cluster, the choice of an Ingress server also impacts security. You can use it to terminate TLS connections from clients before they access your services. Be sure to include a key management strategy, including a Key Management Service or another secure vault.

    Remember to follow the same security practices for your Kubernetes cluster as you do for any other part of your network infrastructure. Watch for OWASP Top 10 and OWASP API Top 10 vulnerabilities as well as logic-based threats.

    (Hint: Traceable watches for common and logic-based vulnerabilities by learning the business logic of your microservice applications. Check it out for yourself here).

    Finally, make sure your ingress plays nicely with mobile and IoT devices if you serve those clients.

    Install Security Cameras: Secure and Monitor Microservice Communications

    Video doorbells and security cameras are becoming commonplace. Homeowners want to know what is happening in and around their house.

    Securing and monitoring within your Kubernetes cluster is equally critical. Make sure that microservice communications are protected, and you know what requests are being sent between services.

    Consider point-to-point encryption between all microservices. And ensure real-time API monitoring for both REST and gRPC protocols.

    Zero Trust principles not are becoming more popular as new technologies are appearing that support it. Zero Trust is an operating model where no traffic is trusted by default, inside or outside your network.

    Within Kubernetes, implementing this model means verifying every request, client, or object trying to connect to your services. Nothing happens within your cluster unless the user or service account has proven that they have permission to act.

    Zero Trust is essential to cloud-native security. At any moment, dozens or hundreds of services are trying to perform actions and share information. Zero Trust ensures that every request is validated and there are no holes due to the assumption that internal traffic is automatically safe.

    Protect Your House

    The world of microservices and cloud-native architecture unlock countless opportunities for businesses today. But new technologies also come with new dangers; new opportunities for malicious actors to steal sensitive information.

    We’ve discussed six essential factors for securing your Kubernetes architecture:

    1. Choosing the underlying platform and control plan configuration
    2. Vetting and securing the containers running in your environment
    3. Implementing cluster partitioning and access control
    4. Defining inter-pod communications
    5. Choosing your Ingress architecture (protecting your “front door”)
    6. Securing and monitoring your microservice communications

    With these factors in mind, what should your next steps be?

    If you have an existing Kubernetes installation, use these factors as a mini-audit. Review your current policies and see how well they match up in these six areas.

    If you’re planning your first Kubernetes installation, use these factors as a guide to making sure you cover all of your bases. Meet with implementers and make sure you have a plan for all of these factors.

    Then your Kubernetes environment will be a happy home for your microservices.

  • Web Application Security is not API Security

    Web Application Security is not API Security

    Do you follow the same procedures to secure a web application as you do an API? Is there a difference between the two?

    We’ve spoken about API security quite a bit in the past few months because we believe that there are critical differences between API security and traditional web application security. A lack of understanding of those differences is dangerous.

    Let’s look at the differences between the two and why you should treat API security differently from application security in general.

    What is API security?

    API security is the practice of defending web APIs against attacks. Building APIs, typically with microservices as the foundation, has become a growing trend. Many mobile applications and websites send and retrieve data using APIs, even if the end user is unaware of this fact.

    APIs are different from traditional web applications, and those differences can lead to critical security issues.

    What Makes APIs Different From Traditional Web Applications?

    I’ll answer that question with a picture, then proceed to “drop the mic.”

    Here’s the entire Netflix architecture, comprised of about 700+ microservices. (Source)

    (Picking the mic back up.)

    The above picture illustrates why APIs are fundamentally different from traditional web applications. What was once one request to one server has become dozens or hundreds of requests to dozens or hundreds of microservices.

    Previously, the work was relatively easy; defend one large application. Now, you have to protect hundreds of small web applications and the data they access. Authentication and authorization don’t look the same. The built-in session management of your favorite framework has gone out the window. Each microservice is its own little kingdom.

    In addition, you now have to know where all of these API endpoints reside, what version they’re running, and how to scale them when demand increases.

    Finally, changes to the development and deployment environment cause changes in how malicious actors attack applications. Are you familiar with the new ways attackers target APIs?

    What Are the Most Significant Threats Against APIs?

    The OWASP API Top 10 project outlines 10 dangerous risks with APIs. (See this post for the breakdown.)

    Instead, let’s look at the big themes the API Top 10 brings to the forefront. Then we’ll discuss some specific breaches that illustrate what happens when APIs are vulnerable.

    Authentication and Authorization Win Top Prize

    Okay, maybe “Most Likely To Get You Hacked” isn’t much of an award, but authentication and authorization are the most prolific and dangerous API security flaws.

    Authentication and authorization in APIs feel like a new world for many developers. A development framework doesn’t manage a session, but instead, applications pass JSON Web Tokens (JWT) around with claims attached.  In a nutshell, every microservice must verify the caller’s identity and permissions before performing any work on their behalf.

    As the number of APIs grows, it’s more likely that developers will miss some authorization checks, and a data breach is waiting to leap out and strike when you least expect it.

    API Endpoints Are Everywhere

    I remember taking my two-year-old daughter to Disney’s Magic Kingdom during spring break. I had to slip a kiddie leash on her to make sure she didn’t disappear in the crowd. It was challenging to keep track of only one child in that vast mass of people.

    An explosion of microservices fills your infrastructure with a crowd of endpoints, and kid leashes don’t seem to fit Docker containers very well. It’s easy for APIs to disappear.

    Unfortunately, these “shadow APIs,” whether spun up by a developer for testing purposes or just an old version left out in the wild, can become a point of attack. They may not be secure, and if you don’t know they’re still publicly exposed, someone could be attacking it without your knowledge.

    Examples of Real API Vulnerabilities

    Let’s illustrate the differences between API and web app security by looking at real vulnerabilities.

    Shopify “Collaborator” Vulnerability

    Security researcher Uzsunny found a critical flaw in the Shopify “collaborator” functionality that allowed an attacker to assign themselves the “collaborator” role on any store. This feature unlocks all sorts of administrative functionality.

    It turns out that the API endpoint that handles this collaborator business logic didn’t verify that the request to add a collaborator to a store came from the store manager. Therefore, anyone could call that endpoint with the right arguments and get admin rights to any store on the Shopify platform.

    Check out our detailed post on how this vulnerability works and why it’d be hard to detect.

    Facebook Authentication Bypass Using Shadow APIs

    Obscurity isn’t security, and determined attackers will find forgotten API hosts. The AppSecure cybersecurity research team found a way to gain access to any Facebook account via a couple of API endpoints Facebook forgot existed. The AppSecure team received a $15,000 bug bounty.

    Although found in 2016, this bug illustrates a kind of vulnerability prevalent in API architectures. This bug was subtle but demonstrated how the smallest crack could let an attacker run amok.

    The bug existed in Facebook’s password recovery logic. When a user requested to recover their account because of a forgotten password, they received a random six-digit code via text message. They enter the code in the browser, which sends an API call with the code.

    Facebook placed rate-limiting on the endpoint to protect against brute-force attacks. The API blocked client requests after 10 failed attempts. However, API endpoints existed on other hosts, and Facebook’s engineers didn’t realize it. An attacker could send payloads to “beta.facebook.com” and “mbasic.beta.facebook.com” and brute force the recovery code. These endpoints didn’t have the ten try limit.

    Check out our detailed post on this vulnerability for more on how modern app sec tools probably would’ve missed this vulnerability.

    Uber API BOLA Vulnerability

    Broken Object Level Authorization (BOLA) is number one on the API Top 10 list. Uber’s API had this vulnerability. Thankfully, it was discovered by security researchers before malicious actors did damage (as far as we know). But it illustrates well how dangerous BOLA can be.

    The vulnerability leaked sensitive information, including an authentication token that could be used to perform a full account takeover.

    The vulnerability appears when a new driver joins the Uber platform. The browser sends the “userUuid” to the API endpoint, and the API returns data about the driver used to populate the client.

    Unfortunately, the API endpoint didn’t check if the calling client had the authorization to view its returned details. An attacker could add another “userUuid” and get a sizable JSON object with the other user’s account details, including first and last name, email address, and user identifiers.

    This vulnerability illustrates that revealing too much information is dangerous for any API (Excessive Data Exposure is number three on the Top 10). Also, inadequate authorization checks can lead to account takeover with minimal effort.

    Check out our detailed post to learn more about this vulnerability.

    The Future of API Security

    Application security technologies such as Web Application Firewall, Next Generation Web Application Firewall, and Runtime Application Self-Protection don’t typically find the kinds of vulnerabilities we’ve discussed. These attacks present as ordinary traffic, so many defenses let them through.

    The future of API security lies with business logic. Application security tools have to understand the application’s context and business logic to know that non-managers shouldn’t be adding collaborators to a store or that a client shouldn’t access that user ID’s information.

    Traceable AI uses machine learning to learn the application’s business logic, so these types of attacks are found and stopped. See Traceable AI in action and see what the future of API security looks like.