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 Top 10 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:
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
There are several approaches to validating input with the Apigee platform:
- JSONThreatProtection checks the JSON payload for threats.
- XMLThreatProtection checks the XML payload for threats.
- SQLCodeInjection can be handled using the RegularExpressionProtection policy.
Validate content types:
- Request - Use conditional logic in the proxy flow to check Content-Type. Use the AssignMessage policy or RaiseFault policy to return a custom error message.
- Response - Use conditional logic in the proxy flow to verify Content-Type. Use the AssignMessage policy to set a Content-Type header, or use an AssignMessage or RaiseFault policy to return a custom error message.
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.
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.
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.
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 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
- 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.
- The Teams feature provides additional capability to restrict access to proxies, products, and apps.
- Configure data masking to hide sensitive data from users.
- Create encrypted key value maps to store sensitive key/value pairs, which appear masked in the Edge UI and in management API calls.
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.
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)
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.
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.
- 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.
- 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.
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.
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.
- 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.
- 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.