Cloud Security Basics: Protecting Your Web Applications

Securing cloud-based web applications requires an understanding of the ways attackers can exploit the vulnerabilities and misconfigurations that occur in these environments. In this blog, we explore these eight common cloud security concerns:

1. The shared responsibility model
2. Common web application vulnerabilities
3. Data exposure and cloud resource misconfigurations
4. Domain Name Server (DNS) record takeovers
5. Insecure APIs
6. Software supply-chain attacks through dependency confusion
7. Software-as-a-service (SaaS)-based application permission management
8. Resource exhaustion and financial loss

In addition, we provide helpful best practices to secure your web applications and, lastly, for Tenable customers, we offer an overview of how Tenable.io Web Application Scanning can help.

Cloud shared responsibility model

Cloud providers offer multiple hosting services for web applications and have built their shared responsibility models describing how both the customer and the cloud providers share the security responsibility. Although this model can slightly differ between the cloud providers, they almost all share the same principles with two crucial aspects all customers are accountable for:

• Web application code security: Writing secure code is the customer’s responsibility. Cloud service providers do not patch the code when a vulnerability exists. In some cases, a cloud provider may offer services to help mitigate the issues, such as web application firewalls (WAF). Even in the case of some software-as-a-service (SaaS) applications that are developed and maintained by third-party vendors, responsibility may fall to the customer, not the vendor, to trigger manual updates.
• Identity and access management: The customer is responsible for defining identities in the context of its web application and must determine how the permissions model is established and applied to its users.

Source : Tenable, November 2022

When each of these is overlooked, attackers can infiltrate a customer’s environment and wreak havoc. In a previous blog post, Tenable CTO Glen Pendley detailed three key takeaways all infosec leaders should consider about the shared responsibility model to ensure organizations are meeting their security obligations as a part of the model.

Common web application vulnerabilities

Web applications deployed on cloud infrastructures can suffer the same vulnerabilities as applications deployed on-premises. Even if cloud providers offer additional security services, which are often optional and require an advanced configuration, security flaws present in a given application are not automatically patched.

Common web application vulnerabilities like SQL injections, code injections, Server-Side Request Forgery (SSRF) or XML External Entity injections (XXE) can still exist in the application and be exploited by attackers.

However, the impact of these vulnerabilities can be more severe on cloud infrastructures as an attacker may be able to reach other cloud resources. This could include gaining access to more sensitive information or performing arbitrary modifications, depending on their permissions.

Data exposure and cloud resource misconfigurations

According to the 2022 IBM cost of a data breach report, 45% of the data breaches studied occurred in cloud environments. By design, cloud providers offer services that are, most of the time, exposed on the internet by default. Due to the open nature, users are required to configure additional security controls to restrict access to sensitive data.

Depending on the web application cloud resources usage, data exposure can arise from different sources:

• Development and CI/CD-based files: CI/CD DevOps tools automate application builds and deployments. A common setup for CI/CD environments includes a version control system like Git to track changes and ensure version and release management. However, depending on the tool and how it’s used, sensitive information such as API keys, user credentials or private keys can be inadvertently hardcoded into files and then published along with the application. By exploiting the exposed data, attackers can gain access to internal systems and try to exfiltrate private data. There are different ways this can happen:
  • Utilize public version control system and repository: For example, if an internal application has its code repository public on GitHub, attackers can retrieve both the source code of the application and the sensitive data and use it to gain further access compromising the cloud customer.
  • Failure to exclude sensitive files: If the deployment chain does not properly exclude files containing confidential information when pushed to the production environment, an attacker enumerating the hosted content on the application could discover these files and abuse the sensitive information.

• Cloud resources misconfiguration: Web applications often use other cloud services to get benefits from the scalability and avoid managing dedicated servers for some features of their application. Unfortunately, misconfiguration of these resources can introduce risk to the application. Here are two common examples of misconfigurations:
  • Storage bucket permissions: Many cloud providers offer customizable permission controls, making it possible for the content within the storage bucket to be publicly available to even unauthenticated users. If the permissions are improperly configured, attackers can retrieve sensitive data or even push content, allowing the attacker to host malicious data. Microsoft BlueBleed’s recent disclosure demonstrates the impact of this kind of misconfiguration. Additionally, the attacker may deface a website or inject malicious resources, such as JavaScript content, that would be executed in each user’s browser in the context of the target web application.
  • Identity management: Cloud providers sometimes offer identity management services like Microsoft Azure AD or Amazon Cognito. These resources, even if provided by the cloud provider, require an accurate configuration in order to avoid misconfigurations that attackers may abuse. This article describes a real scenario where Amazon Cognito was attacked because misconfigurations provided an attacker the opportunity to target a web application without any exposed signup feature. The attacker was able to create a privileged account on the AWS tenant hosting the web application and get access to the AWS administration console.

DNS record takeovers

A DNS record takeover is when an attacker hijacks a subdomain of an intended target domain. This occurs in two common situations when:

• A common canonical name (CNAME) DNS alias is configured in the customer domain DNS zone to create an internal domain name targeting a third-party service which is not yet configured to use it. In this scenario, the attacker would claim this subdomain on this third-party service and host his own content.
• An ‘A’ DNS record is configured to target a specific resource whose address is dynamically assigned by the cloud provider and no longer allocated to this resource. The attacker would perform multiple claims until he finally ends up with the target IP address being allocated to his own resource.

Depending on the service and application, DNS takeover attacks can vary from an attacker performing a simple content injection to capturing sensitive data or even setting up a realistic phishing application.

Below is a diagram that illustrates this class of vulnerabilities, which is also described in Microsoft Documentation along with the recommended mitigation:

Source : Tenable, November 2022

Insecure APIs

Internal or third-party APIs are commonly used to process application logic for cloud-based web applications, especially when they are built upon a microservices architecture. However, these APIs may not meet the secure design principles, resulting in security vulnerabilities that directly impact the application.

The Open Web Application Security Project (OWASP) establishes a top 10 list of the most common vulnerabilities for APIs. These include:

• Insecure direct object references (IDOR): By taking advantage of an IDOR vulnerability, an attacker can perform arbitrary requests on objects they should not be able to access. For example, if a web application uses an API for its user management, attackers may be able to update information about another user, gain privileges on the target application or access and leak sensitive information. Because IDOR vulnerabilities may be present in many APIs, multi-tenant web applications are more likely to be adversely impacted.
• API authentication: Often the first level of security, API authentication ensures that only authorized users can access the API or its endpoints. Most APIs rely on API keys or tokens (JSON web tokens are the most common tokens) to enforce authentication. However, if the API does not enforce strong security passphrases for the JSON web tokens signature or does not properly verify the token signatures, attackers can impersonate the web application users and perform authenticated requests to the backend API.

Software supply-chain attacks through dependency confusion

In December 2020, the SolarWinds supply chain attack demonstrated the importance of securing your software development environment and software delivery mechanism. The SolarWinds attack revealed how software compromised at its source can have devastating consequences, especially with a large customer base.

In February 2021, security researcher Alex Birsan described a new web application attack vector known as dependency confusion. Birsan analyzed package manager dependencies, to demonstrate the potential to perform code execution on a software build chain by claiming package dependencies used by the application but actually not claimed on public package registries where they are retrieved from.

Additionally, a similar approach, WordPress Plugin Confusion, was tested by other security researchers. This test showed that claiming a WordPress plugin could also allow attackers to hook into WordPress vulnerable instances.

SaaS-based applications permissions management

SaaS-based applications are easier for cloud customers to manage, especially when it comes to infrastructure and application patching. However, many SaaS administrators often overlook the need to properly configure and ensure that necessary permissions are applied, particularly for data access and identity management.

Failure to properly enforce permissions has a real-world impact, as the following cases illustrate:

• Salesforce Community misconfigured instances gave guest users higher-level permissions on objects they should not have access to and led to sensitive information being leaked to unauthorized users.
• A popular Atlassian Jira misconfiguration revealed how a permission issue on filters could allow any user to access sensitive information and use it to conduct further attacks, such as realistic phishing campaigns.
• Leaky Helpdesk demonstrated that, by default, Zendesk sets the ticket attachments as public. This default permission setting means anyone who has the link can access the attachments without authentication.

Resource exhaustion and financial loss

Cloud infrastructure is used to have a highly resilient service when distributed and scaled across multiple data centers and even across multiple providers, helping their customers to reduce the risks of Denial of Services (DoS) attacks on their services.

Due to the “pay as you go” subscription model, many cloud customers pay based on the resources they use, including CPU usage, memory, storage or bandwidth usage, among others. If an attacker takes advantage of these resources, cloud customers are the ones to foot the bill.

For example, attackers could exploit a storage bucket to upload and house large files, forcibly increasing storage costs.

Additionally, attackers can run up significant bandwidth costs by taking advantage of an unmonitored cloud function that transfers data from a given endpoint.

While the individual costs from this kind of abuse are not necessarily high, without proper monitoring in place, persistent attacks may result in hefty costs.

Mitigation takeaways

Cloud vendors can offer various security services to help their customers protect web applications, but ultimately it requires customers to be on top of their own cloud security.

Here are some helpful best practices to follow for your own cloud web application security:

• Define and control the responsibilities of each actor involved in the development and hosting of your web applications.
• Continuously assess web applications and cloud resources for vulnerabilities.
• Inventory all of your web application components and the cloud resources they use. Package dependencies analysis must be part of this review, to ensure that all these dependencies are expected with the proper version and served from known and trusted sources.
• Configure permissions for all cloud resources and SaaS-based applications to follow the least privilege principle, reducing the risk of exposing sensitive data to an unauthorized actor.
• Control that the software development and deployment chain does not expose sensitive information to unauthorized actors.
• Enforce mandatory assessments of all microservice-based architectures to avoid backend services becoming compromised or pivoted to other cloud customer assets.
• Ensure logging is enforced on each component used by web applications and alerts are reviewed to detect potential abuses.

How Tenable.io Web App Scanning can help

Tenable.io Web App Scanning provides a list of comprehensive plugins designed to help identify cloud technologies used in web applications and related vulnerabilities:

• Plugins specific to cloud technologies are designed to detect cloud services used by web applications and identify common issues, such as data exposure, CI/CD permission controls and SaaS application misconfigurations.
• Plugins mainly focusing on APIs detect insecure API usage in web applications for both representational state transfer (REST) and GraphQL technologies.

Plugins are added on a regular basis to cover security risks related to web applications in cloud environments and common SaaS application misconfigurations.