API SECURITY: THE FULL STORY

SPEAKERS

2

PhilippeLeothaudChiefArchitect&CSO

IsabelleMaunyCTO

How to reach us: philippe.leothaud@42crunch.comisabelle.mauny@42crunch.com

FIRST A BIT OF VOCABULARY!

3

SECURITY HAS TWO DIFFERENT ASPECTS

➤Putting in place a security architecture achieving security goals

➤Preventing from attacks against this security architecture.

4

SECURITY GOALS OVERVIEW

5

INTEGRITY Message has not been tampered with

CONFIDENTIALITY Message can only be seen by target audience

AVAILABILITY Resistance to attacks, such as Denial-of-service (DDOS)

AUTHENTICATION Identity of the caller is known.

AUTHORIZATION We can guarantee the caller has proper permissions to access a resource

AUDIT System has non-perishable trace of all machine/human actions.

NON-REPUDIATION There is (legal) proof that the action has taken place.

ATTACKS AND COUNTERMEASURES

6

ASSETA resource of value such as the data in a

database or on the file system, or a system resource (such as an API)

VULNERABILITYA weakness or gap in security program that

can be exploited by threats to gain unauthorised access to an asset.

THREAT Anything that can exploit a vulnerability and obtain, damage, or destroy an asset.

ATTACK/EXPLOIT An threat in action, to harm an asset.

COUNTERMEASURE A safeguard that addresses a threat and blocks attacks.

SECURITY IS A LAYERED APPROACH

7

APPLICATION SECURITYMeasures taken throughout the code's life-cycle to

prevent gaps in the security policy of an application, i.e. flaws in the design, development, execution of an

application

SYSTEM SECURITY Control of access to a computer system's resources, specially its data and operating system files.

NETWORK SECURITYPolicies and practices adopted to prevent and monitor

un-authorized access, misuse, modification, or denial of a computer network and network-accessible resources.

APPS INFRASTRUCTURE EVOLUTION

API CENTRIC INFRASTRUCTURE

➤ HTTP (mainly), REST/JSON and the ecosystem

➤ An application is a dynamic orchestration of multiple API calls

➤ Calls may be targeted to ➤ enterprise own APIs running internally

➤ enterprise own APIs running in the cloud

➤ external (public/partner/SaaS) APIs running over Internet

9

Internal Applications Legacy Systems

Application Server

Databases

Integration Layer (ESB)

App1

Services &MicroServices

SaaS ApplicationsThings

APIs

THE WORLD AS WE KNEW IT

➤ Established Perimetric Defense

➤ Defense in-depth

➤ Limited set of client types

➤ Limited number of entry points for apps

➤ Slow delivery of apps

10

TODAY

➤ No more clear security perimeter

➤ Multiplication of endpoints, internally and externally

➤ Multiplication of protocols

➤ Uncontrolled client types, typically devices, which may have been compromised

➤ Fast delivery of apps, some shortcuts are taken

➤ Microservices architectures are multiplying the set of OS/frameworks to secure and manage.

➤ Cost of explosion of C in MVC (Controller)

11

SECURING A SINGLE API

12

API ECOSYSTEM STATE OF THE ART

13

GOAL TACTIC STANDARDS

INTEGRITY/CONFIDENTIALITY(Transport)

Encryption/Signature TLS

INTEGRITY(Message) Digital Signatures JWS

CONFIDENTIALITY (Message)

Encryption JWE

AVAILABILITY Rate Limiting/ThrottlingNo standard - Must be part of API

Management solution

AUTHENTICATION Identity ManagementOpenID Connect

OAuth2 Authentication flows

AUTHORIZATION Fine-grained permissions model OAuth2 + ????

AUDIT Write transactions to permanent storage (encrypted/signed/protected)

No standard - Must be part of API Management solution

NON-REPUDIATION Write transactions to permanent storage (encrypted/signed/protected)

No standard - Must be part of API Management solution

A WORD ABOUT OAUTH…

➤OAuth was created to solve a specific problem: allow a resource owner to give access rights to their personal data to an application.

➤However, whenever the need to control the access to enterprise data, OAuth may not be enough, or may not scale.

➤Need to introduce fine-grained authorization, based on information on the resource consumer.

• Engage XACML engine to take decision

• Pass JWT token to back-end so that it can take a decision.

14

SECURING APPLICATIONS

15

Madrid App

Internal APIs

Stripe Payments API

Starbucks API

GoogleMaps API

ORCHESTRATION AT APP LEVEL

➤ Who manages credentials for SaaS apps ?

➤ Where are those credentials stored ?

➤ Where do we control the application flow of the APIs?

➤ Security (in particular of data at rest) is handled at app level

➤ Complexity

➤ Deployment Agility

16

ALTERNATIVE APPROACH

17

Enterprise Border

Stripe Payments

Starbucks

GoogleMaps

API

s Fi

rew

all

API

Med

iatio

n

SEC DEVOPS

SECURITY TESTING IS FULLY PART OF DEVOPS

➤API-led architectures are bringing unparalleled agility to enterprises, with the ability to leverage business logic exposed internally and externally, coupled with a scalable architecture.

➤A study shows that applications will likely need to be released around 30 times per year in order to keep up with innovation driven by customer demand. This is close to impossible without continuous development and continuous testing.

➤Security must not be an afterthought, but rather something you continuously consider in the development and deployment cycles. 

19

If security slows down innovation, it will be bypassed.If security slows down innovation it will be bypassed!

RECOMMENDATIONS

20

TARGET API INFRASTRUCTURE ARCHITECTURE

21

Application Server

Databases

Integration Layer (ESB)

App1

Services &MicroServices

SaaS ApplicationsThings

Security Policies

Web Apps and APIs Firewall

Security Policies

API Security Policies

ENFORCE THIS COMPREHENSIVE API SECURITY POLICY1.White-listing enforcement: URLs + queryString parameters + HTTP Verbs + HTTP headers control CORS, X-Frame-Options, Strict-Transport-Security header (HSTS), etc.

2.Anti-DOS protection (technical quotas)

3.Replay attacks protection(using a nounce)

4.Check maximum input message size

5.Decrypt eventually

6.Verify signatures if any

7.Check JSON/XML payload to protect parser (size, complexity, depth, etc.)

8.Validate/sanitize input JSON/XML using schema

9.Check for applicative attacks (SQL Injection, XSS, CSRF, Clickjacking etc)

10.Authentication

11.Authorization

12.Enforce application flow and session handling

13.Validate/sanitize output JSON/XML using schema

14.Check maximum output message size

15.(Optional) Sign output message

16.(Optional) Encrypt message or parts of message)

17.Control outgoing headers (mainly CORS headers).

22

SUMMARY THOUGHTS

➤While OAuth and OpenID connect are important, they are clearly not enough

• Need to take holistic approach including reaching all security goals

➤Complement OAuth with a fine-grained, enterprise level authorization model

➤Comprehensive security

➤Application security starts at development time (SecDevOps)

➤Favor deploying API orchestrations on the server side in order to enforce security and proper order of API calls.

• Even when deployed on the client side, enforce application flow control on server side.

23

REFERENCES

➤Defense in-depth • http://searchsecurity.techtarget.com/definition/defense-in-depth

➤OWASP REST Security Cheat Sheet • https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

➤Transport Layer Security Cheat Sheet • https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet

• https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

➤HTML5 Security Cheat Sheet • https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage

24