Creating a Safe Environment for Under-Protected APIs WHITEPAPER

SHARE THIS WHITEPAPER TAE OF CONTENTS

ÐÐBackground ...... 3

What are APIs?...... 3

ÐÐAPIs in Modern Applications...... 3

Rapid FaaS Evolution is Driving API Adoption ...... 4

ÐÐSecurity Concerns of Distributed API Architecture...... 4

The API Security Visibility Problem...... 4

API Security Risks and Vulnerabilities...... 4

ÐÐDesigning a Secured API Environment...... 6

Inline API Security Measures...... 6

Radware API Security Technology...... 6

ÐÐReferences...... 7

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 2 BACKGROUND The newly published OWASP Top 10 2017 Release Candidate introduces new application security risk protection for APIs. This is a common concern as modern applications and services rely heavily on API integration and communication. While on one hand APIs provide synergy and efficiency to business operations by simplifying the architecture and delivery, on the other it introduces a wide range of risks and vulnerabilities. The combination of growing adoption and security risks was the major driver for this new entry to the OWASP list.

What are APIs? API (Application Programming Interface) is a set of tools and protocols used to develop application software. This interface predefined request–response message system exposes reliable content and operation negotiation (typically expressed in JSON or XML). The most common API protocol styles in modern architectures are REST and SOAP. REST is by far the most common one.

Figure 1 - Distribution of API Protocols and Styles, based on directory of APIs listed at ProgrammableWeb, May 2016.

Publicly available APIs allow sharing of content and data openly between communities and applications. ProgrammableWeb, one of the world’s leading information sources about -based APIs, lists more than 17,444 APIs in its API Directory. This number has almost doubled during the past 4 years. Some outstanding companies have built API businesses that match or exceed their original focus. For example, Salesforce reportedly generates 50% of its revenues through APIs, eBay nearly 60% and Expedia a 90%.

APIS IN MODERN APPLICATIONS APIs are being used in a variety of modern applications, where the most common examples are:

ÐÐMobile applications ÐÐApplications for IoT devices ÐÐEmbedding public and 3rd party APIs as external services into an existing application (e.g. Google Maps APIs)

DevOp environments, with the ever-increasing demand for continuous delivery, requires complete process automation utilizing APIs across the board:

ÐÐService provisioning and management (e.g. AWS API) ÐÐPlatform management apps ÐÐContinuous delivery process automation

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 3 Rapid FaaS Evolution is Driving API Adoption Serverless architecture - or FaaS (Functions as a Service) - offers a model where the operational unit is a set of function containers rather than a web server. These functions are APIs exposed for the client side application, which may invoke these APIs upon relevant client side event. A simple example would be an IoT device that would push a notification for a temperature reaching a predefined threshold.

In a FaaS architecture, the management of function containers is greater in complexity than just managing lasting virtual machines. These function containers are created upon request and may disappear immediately after being used. This approach simplifies the development process and reduces OPEX dramatically. It is important to state that APIs are not tightly coupled with FaaS and are being widely used in other architectures and with web applications.

SECURITY CONCERNS OF DISTRIBUTED API ARCHITECTURE The API Security Visibility Problem API vulnerabilities are hard to monitor and do not stand out. Traditional application security assessment tools do not work well with APIs or are simply irrelevant in this case. DAST (Dynamic Application Security Testing) and application scanning tools, for example, cannot invoke the “Since many Application API because they cannot generate well-formed requests. Even if the tool knew whether the request body should be a JSON or an XML and even has a Programming Interfaces schema for the API, it is still difficult to provide the data required to correctly invoke an API. are mission critical and Similarly, SAST (Static Application Security Testing) tools don’t do a great job in scanning API code, as in a typical API, third-party frameworks and involve crucial business libraries use custom methods to read a JSON or XML document from the body of the HTTP request, functionalities and parse it, and pass the data into the API code. These methods are different from one another and are subject to changes, limiting the success rate of processes, API security static tools.

When planning for API security infrastructure, has become a major authentication and authorization must be taken into account, yet these are often not addressed properly in many API security solutions. As clearly stated in concern and challenge the OWASP Top 10 2017 Release Candidate, “all the different types of injection, authentication, access control, encryption, configuration, and other issues for organizations. can exist in APIs just as in a traditional application.”

API Security Risks and Vulnerabilities Web services such as APIs are vulnerable to all types of attacks and threats against web applications: ”

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 4 Vulnerability/ Attack Risk Protections/Controls API transaction Confidentiality and integrity of - TLS is required to secure the communications between the client manipulations data in transit and APIs for transport confidentiality and integrity of data in transit.

TCP protocol tcp packet replay - Once detected the evasion attempt or the protocol manipulation attacks and tcp packet fragmentation an immediate TCP Termination shall be taken. evasion tcp packet reordering techniques HTTP protocol Manipulation of HTTP headers - HTTP protocol parsing and enforcement of HTTP RFC attacks and (for instance - content-type protects against various HTTP attacks such as NULL byte evasion header that is not aligned with injection, encoded attacks, HRS attacks, content-type mismatch techniques the content sent in the body, etc. etc). - Traffic normalization for evasion attacks detection. Peacetime patterns shall be used as a reference as encoded attacks can easily bypass security solutions. - Message size policy enforcement - on HTTP message, body, headers and JSON/XML element sizes - secures the application against buffer overflow attacks, resource exhaustion and other availability attacks on API infrastructure.

POSTed JSONs May eventually reach - Strong Typing and Positive Security model provide tight and XMLs , leading to protection to API infrastructure. It will be impossible to generate Injections injections. most of the attacks if, for example, the only allowed value type in the JSON element is an integer with the value rage of 1 – 100. - XML/JSON validity check and Schema Validation is extremely important security protection. Types, value ranges, sizes and order of XML elements must be configurable. - SQL and no-SQL Injection protections through sanitizing and validating user inputs and rule-based attack detection.

Insecure Direct Manipulation of state - Session and field protections against manipulation. Object References information in parameter - Input validation in transactions to detect injections of value storing the account references. number may allow access to unexpected data.

Invalidated External entity embedding - Validation of user inputs for external domains in parameters and Redirects malicious content in the submitted forms and form fields. service or application.

Data Leakage Credit cards, social security - Data Leak Protection to make sure error messages and numbers, passwords or any sensitive information is not leaking out to the potential attacker. other sensitive data may leak Data structures and schemes of private information shall be through the API response. recognized and guarded. Also, 500 error messages may leak architecture information exposing server and data- storing types.

Access Violations Unexpected users may - Access Control policy management with: and abuse of APIs invoke APIs they should not o IP-based and geo Location restrictions when relevant have access to or perform o Access restriction to particular APIs where, for example, operations they should not be some APIs should be exposed for public access while others are allowed (e.g. delete a license just for internal use. vs. just generating a license). o Access restrictions to specific HTTP methods where the set of operations that is allowed for some users is restricted for others. For example, a user can generate a license but cannot delete the license once generated.

DOM XSS An API client side vulnerability - XSS protection based on rules and signatures of known attack that may lead to additional patterns. These rules and signatures must be continuously attack vectors. reviewed and updated.

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 5 Session Session hijacking and - Session Management protection of the API key, which is Management attack privilege escalation attacks. posted as a body argument or in the cookie. Buffer Overflow Large JSON/XML - Strong Typing and Positive Security model provide tight and XML bombs element values can affect protection to API infrastructure. It will be impossible to generate performance, resource most of the attacks if the only allowed value type in the JSON consumption and service element is an integer with the value rage of 1 – 100. availability. - XML/JSON validity check and Schema Validation is extremely important security protection. Types, value ranges, sizes and order of XML elements must be configurable.

Bot attacks - Sophisticated application- - Limiting the number of attempts or identical actions per layer bot attacks application or per API is an important protection against service - Service Abuse abuse (for informational APIs), brute force attacks and denial-of- - Brute Force service attacks. - Scraping and data extraction

DDoS Attacks - Network and application- - DDoS protection – Attacks against applications can come in based DDoS attacks mass, looking to disrupt services or retrieve access. - Distributed Denial of Service Some attacks focus on rendering the web application layer unreachable, causing a denial-of-service state. In essence, one HTTP request can lead the server to execute a large number of internal requests. Multiple requests can consume all its resources. There are few techniques to do that, including randomizing URLs, API keys, and bypassing the application caching. Platforms such as WordPress and Joomla - and even

DESIGNING A SECURED API ENVIRONMENT Inline API Security Measures WAFs and API gateways are the two major inline security tools for API protections. While API gateways do offer usually authentication and authorization features, their HTTP and OWASP Top 10 protection offering is either limited or absent. On the other hand, not all WAFs understand the differences between APIs and regular web applications, even when both may use the HTTP RFC as a baseline. The obvious example is the HTTP method use in REST APIs. While it is extremely unlikely for a web application to accept HTTP Requests with DELETE HTTP method, it is a common practice with REST API call to support this method and other potentially risky methods for web applications such as PUT.

Radware API Security Technology Radware secures APIs as part of its flexible and scalable web application security solution and is recommended by NSS Labs and ICSA Labs across on-premise, cloud, virtual, stand-alone or integrated, inline and out-of-path deployments. Radware addresses all OWASP Top 10 security risks including the newly introduced A10 – API protection. Beyond all the required protections discussed above, including SQL injection, broken authentication, XSS, CSRF, DDoS, etc., Radware’s web application security technology features additional attack correlation capabilities which allows blocking of repetitive attack sources by managing a penalty score for security violations per source. Once an attack source reaches a predefined score threshold, it will be blocked.

Radware introduces a unique auto policy generation mechanism to reduce the complexity of keeping evolving environments secure. Advanced machine learning algorithms learn XML and JSON structures and schemas for enforcement as part of the validation phase and create a security policy based on those. Moreover, these algorithms are able to track changes in the application and perform automatic updates in real-time, thus resulting in an adaptive security model.

As part of Radware’s Attack Mitigation System, Radware’s WAF leverages DefenseMessaging - a unique communication mechanism with Radware’s dedicated DDoS protection solutions - to provide best-of-breed Layer 7 DDoS mitigation at the perimeter.

CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 6 REFERENCES

://www.programmableweb.com/api-university/understanding-realities-api-security https://www.owasp.org/index.php/REST_Security_Cheat_Sheet https://medium.com/capital-one-developers/building-a-serverless-rest-api-in-go-3ffcb549ef2 https://techcrunch.com/2016/05/21/the-rise-of-apis/ http://blog.octo.com/strategie-d-architecture-api/ http://www.darkreading.com/application-security/what-do-you-mean-my-security-tools-dont-work-on-apis!!/a/d-id/1321050 http://readwrite.com/2011/05/26/soap-is-not-dead-its-undead/

This document is provided for information purposes only. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law. Radware specifically disclaims any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. The technologies, functionalities, services, or processes described herein are subject to change without notice.

©2018 Radware Ltd. All rights reserved. Radware and all other Radware product and service names are registered trademarks or trademarks of Radware in the U.S. and other countries. All other trademarks and names are property of their respective owners. The Radware products and solutions mentioned in this document are protected by trademarks, patents and pending patent applications. For more details please see: https://www.radware.com/LegalNotice/

PRD-API_Security-WP-02-2018/02-US CREATING A SAFE ENVIRONMENT FOR UNDER-PROTECTED APIs | WHITE PAPER 7