OWASP top 10 Web Application threats

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

This document describes various approaches you can use within Apigee to address security vulnerabilities identified by OWASP. For additional approaches documented for Apigee, see OWASP Top 10 2021 mitigation options on Google Cloud.

Overview

API ecosystems experience various attacks from both external and internal clients. Offering and using APIs creates tremendous opportunities for service providers, but it also poses some security risks. Developers must be aware of these challenges and address them when they create and use APIs.

OWASP is an open community dedicated to helping organizations develop, purchase, and maintain trusted applications and APIs. Through the OWASP API Security project, OWASP publishes the most critical security risks to web applications and REST APIs and provides recommendations for addressing those risks.

With Apigee, the API proxy layer can detect, block, and report malformed API requests from the client before the requests are processed on the backend systems, thus mitigating risk and protecting your services. Malformed requests can include any component that makes up the HTTP application-level protocol:

  • URL
  • Headers
  • Path
  • Payload

Malformed API requests can be from known or unknown clients developed by external developers, internal developers, or malicious bots.  These types of requests make up the majority of OWASP threats, but there are additional components of the underlying API proxy layer that can mitigate risks, such as data masking, logging, administration, and so on.

Apigee's intelligent API management platform lets you address the top OWASP API security vulnerabilities seamlessly as you take a consumption-focused approach to designing your APIs and connecting them with your backend systems. Following is a list of policies/configuration that Apigee recommends for the top REST OWASP threats.

Apigee solutions for the 2017 OWASP Top 10

There are many security concerns when it comes to building and securing web applications. OWASP released their list of Top 10 OWASP Security Threats 2017 for web applications.  While there are many parts to a web application, most modern web apps rely heavily on REST APIs.  Apigee is not meant to handle all security needs of a web application, but it can play a pivotal role in securing the REST APIs. Following are the top OWASP security threats with descriptions of how you could use Apigee to help address those threats.

A1:2017 - Injection

To protect against untrusted data injection like SQL, NoSQL, LDAP, and JavaScript, which can result in the execution of unintended commands or unauthorized data access, Apigee provides several input validation policies to verify that the values provided by a client match the expectation before allowing further processing. Apigee Edge, acting as a server for the incoming API requests, checks to ensure that the payload structure falls within an acceptable range, also known as a limit check. You can configure an API proxy so that the input validation routine transforms the input to remove risky character sequences and replace them with safe values.

There are several approaches to validating input with the Apigee platform:

Validate content types:

A2:2017 - Broken Authentication and Session Management

Attackers can access passwords, session tokens, and keys to impersonate other users by taking advantage of implementation flaws in applications. This is more of an implementation problem and not a product issue.  Apigee provides VerifyApiKey, OAuth, and JSON Web Token (JWT) policies, which help protect against this vulnerability.

API key validation

API key validation is the simplest form of app-based security that can be configured for an API. A client app simply presents an API key with its request, then Apigee Edge, through a policy attached to an API proxy, checks to see that the API key is in an approved state for the resource being requested.

Apigee provides support for the generation and validation of API Keys. Apigee generates an API key and secret when a developer app is created and approved that is linked to one or more API products.

The term “API keys” can sometimes mean different things. In Apigee, when the app and product relationship is formed, Apigee generates a client ID and client secret.  Some refer to both the ID and secret as the API key. Some refer to just the client ID as the API key. In the Edge UI, you will see "consumer key" and "consumer secret."

In the VerifyAPIKey policy, just the client ID, or "consumer key," is verified. Developers receive a consumer key when they register their app with Apigee and associate the app with an API product. Developers include the consumer key in calls the app makes to API proxies that are bundled in the API product.

Apigee also supports the ability to import existing API keys from external sources.

For OAuth grant types, both the client ID and secret are used.

OAuth 2.0

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

Apigee's OAuth 2.0 policies let you implement and customize the four OAuth 2.0 grant types. OAuth access token enforcement can be done using the OAuthv2 policy. The consumer must be registered and have an app approved that has granted them access to the API. In return, they will receive an API client ID and client secret. The consumer must go through one of the OAuth grants to be authenticated, which grants them an opaque access token. This token can be used to control access to the API.

JWT

JSON Web Tokens, or JWT, are commonly used to share claims or assertions between connected applications. Apigee provides JWT support using three policies.

  • GenerateJWT tokens (supports HS256 and RS256 signature)
  • ValidateJWT tokens
  • DecodeJWT tokens without validating

A3:2017 - Sensitive Data Exposure

Attackers target sensitive data such as credit card details, social security numbers, log-in credentials, personally identifiable information (PII), and tax IDs to commit identity theft, money theft, fraud, and other crimes. Web applications need to implement encryption, both at rest and in transit, and other strategies to ensure protection of sensitive data.

TLS (Transport Layer Security, whose predecessor is SSL) is the standard security technology for establishing an encrypted link between a web server and a web client, such as a browser or an app. Apigee supports both one-way and two-way TLS.

Northbound TLS (client connecting to the API acting as server) is supported through the use of a Virtual Host configuration. A virtual host can be configured for one-way or two-way TLS.

Southbound TLS (apigee as a client connecting to backend service) is supported through the use of a Target Server configuration.  A Target Server can be configured for one-way or two-way TLS.

Apigee supports many TLS configuration options.

2-way TLS enforcement ensures that the client is using a certificate that has already been onboarded onto Apigee. OWASP also provides TLS best practices.

In Apigee hybrid, TLS is available at the ingress through a host alias, which is a similar concept to a virtual host.

Following are guidelines for securing sensitive data:

  • Use a platform that supports one-way and two-way TLS, which will guard at the protocol level.
  • Use policies such as AssignMessage policy and JavaScript policy to remove sensitive data before it's returned to the client.
  • Use standard OAuth techniques and consider adding HMAC, hash, state, nonce, PKCE, or other techniques to improve the level of authentication for each request.
  • Use data masking settings to mask sensitive data in the Edge Trace tool.
  • Be careful of storing any sensitive data in the cache (or encrypt sensitive data that is stored in cache). In Edge, you can encrypt sensitive data at rest in key value maps.

A4:2017 - XML External Entities

Systems or applications that process XML need to handle "external entity references" in XML—references to files or data that get replaced with the actual data during XML processing. If the applications or XML processors are old or poorly implemented, attackers can hack the data and use it to steal information or launch various kinds of attacks on the system, such as denial of service.

Apigee's ExtractVariables policy lets you extract the content from a request or response and assign that content to a variable. You can extract any part of the message, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters. The policy works by applying a text pattern to the message content and, upon finding a match, setting a variable with the specified message content.

Apigee has a built-in XML parser as part of the platform that uses XPath to extract data. It also has an XMLThreatProtection policy to guard against malicious XML payloads.

A5:2017 - Broken Access Control

After users log in and gain access to a system, proper authorization controls need to be in place so that users can see and do only what they're allowed to. Without strong access controls, attackers can view unauthorized and often-sensitive data or maliciously manipulate data and system behavior.

Apigee supports a layered approach to implement access controls to keep the bad actors from making unauthorized changes or accessing the system.

Access controls for the Edge UI

Access controls for Apigee Developer Portal

  • Configure single sign-on with your company’s identity provider.
  • Configure role-based access control (RBAC) to only allow users access to the functionality and configuration they need on Drupal-based developer portals.
  • Configure developer portals to show specific API products according to user role.
  • Configure the portal to show or hide content based on user role.

Access controls for Apigee runtime API access

  • Access to APIs can be enforced through API keys, OAuth tokens, OAuth scopes, certificates, and other techniques.
  • The API provider configures which resources are available by defining an API product. The access is granted either manually in the UI, through the management API, or through the developer portal. When a developer’s app is granted access to an API product, they receive a client ID and secret that are used in the authentication process.
  • Apigee can integrate with any identity provider to perform OAuth.
  • Apigee can generate JWT tokens or other techniques to send user identity to target services. The target services can use that identity to restrict access to services and data as needed.

A6:2017-Security Misconfiguration

Security misconfigurations are easy to overlook, often because administrators and developers mistakenly trust that the systems they use are inherently secure. Security misconfiguration can happen in many different ways, such as trusting default configurations or making partial configurations that may be insecure, letting error messages contain sensitive details, storing data in the cloud without proper security controls, misconfiguring HTTP headers, and so on. The Apigee platform provides a number of mechanisms to let you control, manage, and monitor security configurations, including reusable shared flows.

A shared flow lets API developers combine policies and resources into a reusable group. By capturing reusable functionality in one place, a shared flow helps you ensure consistency, shorten development time, and more easily manage code. You can include a shared flow inside individual API proxies, or you can go a step further and place shared flows in flow hooks to automatically execute shared flow logic for every API proxy deployed in the same environment as a shared flow.

Apigee product releases ensure protection against libraries with vulnerabilities. Apigee may release additional patches or updates if new vulnerabilities are found. Edge public cloud is patched automatically. Edge for Private Cloud (on premises) customers must apply product patches themselves.

A7:2017-Cross-Site Scripting (XSS)

Cross-site scripting (XSS) lets attackers execute scripts in user web browsers to control user sessions, manipulate web sites, or maliciously impact users in other ways. XSS issues aren't necessarily related to APIs, but Apigee provides threat protection policies that can be leveraged to guard against XSS in the API.  Using regular expressions, either with the RegularExpressionProtection policy or JavaScript policy, check payload and parameter values for JavaScript and other injection-type attacks.

CORS, one of the commonly implemented solutions to the same-origin policy that is enforced by all browsers, can be implemented using the AssignMessage policy.

A8:2017 - Insecure Deserialization

Attackers can use flaws in deserialization for different types of attacks, such as replay, privilege escalation, and injection. Insecure deserialization can also enable remote code execution.

Apigee does not recommend deserialization. However the JSONThreatProtection policy and RegularExpressionProtection policy can help guard against malicious JSON payloads. The JavaScript policy can also be used to scan payloads for malicious content. The cache and other policies can be used to protect against replay attacks. At the infrastructure level, the Apigee platform also has guardrails built in to protect running processes.

A9:2017 - Using Components with Known Vulnerabilities

Because frameworks, libraries, and modules run with full execution and CRUD access, attackers can leverage component vulnerabilities to attack systems.

Apigee's regular product releases ensure protection against component vulnerabilities, especially when specific vulnerabilities are discovered. The Apigee public cloud is patched automatically, and Apigee notifies Edge for Private Cloud customers when on-premises patches are available for installation.

A10:2017 - Insufficient Logging & Monitoring

When you don't adequately perform logging, monitoring, and incident management in your systems, attackers can perform deeper and more prolonged attacks on data and software.

Apigee has several ways to perform logging, monitoring, error handling, and audit logging.

Logging

  • Log messages can be sent to Splunk or other syslog endpoint using the MessageLogging policy.
  • API analytics data can be pulled through the analytics API and imported or exported into other systems.
  • In Edge for Private Cloud, you can use the MessageLogging policy to write to local log files. Log files from each of the running components are available as well.
  • The JavaScript policy can be used to send log messages to a REST logging endpoint synchronously or asynchronously.

Monitoring

  • Use the API Monitoring UI or API to regularly monitor APIs and backends and trigger alets.
  • Use health monitoring to regularly monitor target server backends.
  • Apigee provides recommendations for monitoring Edge for Private Cloud.
  • Apigee also provides best practices that your team can leverage for monitoring your API program.

Error Handling

Apigee offers a powerful, versatile fault handling mechanism for API proxies. Similar to how a Java program would catch exceptions, API proxies can catch faults and determine how to return appropriate responses to clients. Apigee's custom fault handling lets you add functionality such as message logging whenever an error occurs.

Audit Logs

The Apigee platform keeps an audit log that tracks changes to API proxies, products, and organization history.  This log is available through the UI or through the Audits API.

Apigee solutions for 2013 OWASP vulnerabilities

When OWASP updated their list for 2017, some vulnerabilities from 2013’s list were left off. They are still valid threats. The following sections describe how to handle these threats with Apigee.

A8:2013 - Cross-Site Request Forgery (CSRF)

Cross-site forgery requests let attackers forward a user's authentication details, session cookie, and other data to a vulnerable web application over HTTP, tricking the web application into believing the requests are legitimate requests from the user.

Guidelines:

  • This is more of a browser problem, not an API product issue. You can address this vulnerability with OpenID Connect, OAuth, and other techniques.
  • Consider using HMAC, state, hash, nonce, or PKCE techniques to prevent forgery and replay attacks.

A10:2013 - Unvalidated Redirects and Forwards

If a web application performs redirects, but it doesn't validate that redirects are sending users to trusted, intended web sites, attackers can send users to malicious destinations to perform phishing, malware execution, and other attacks.

Guidelines:

  • Use OAuth and enforce validation at each request.
  • Prevent unexpected 302 redirects by checking for response codes in API proxy logic and handling redirects appropriately.