Download - Api days paris-2016-42crunch
API SECURITY: THE FULL STORY
SPEAKERS
2
PhilippeLeothaudChiefArchitect&CSO
IsabelleMaunyCTO
How to reach us: [email protected]@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