API Security: the full story
2 likes724 views
In this presentation, we explain why OAuth and SSL are not enough when it comes to API Security, and that you should also think about addressing other aspects such as confidentiality, integrity, audit or compliance requirements. We expose the tactics to address each of those aspects, and a set of recommendations to apply immediately to your APIs development.
More Related Content
What's hot (20)
Similar to API Security: the full story (20)
Recently uploaded (20)
API Security: the full story
- 1. API SECURITY: THE FULL STORY
- 2. SPEAKERS 2 Philippe Leothaud Chief Architect & CSO Isabelle Mauny CTO How to reach us: [email protected] [email protected]
- 3. FIRST A BIT OF VOCABULARY! 3
- 4. SECURITY HAS TWO DIFFERENT ASPECTS ➤Putting in place a security architecture achieving security goals ➤Preventing from attacks against this security architecture. 4
- 5. 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.
- 6. ATTACKS AND COUNTERMEASURES 6 ASSET A resource of value such as the data in a database or on the file system, or a system resource (such as an API) VULNERABILITY A 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.
- 7. SECURITY IS A LAYERED APPROACH 7 APPLICATION SECURITY Measures 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 SECURITY Policies and practices adopted to prevent and monitor un-authorized access, misuse, modification, or denial of a computer network and network-accessible resources.
- 9. 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
- 10. 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
- 11. 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
- 12. SECURING A SINGLE API 12
- 13. 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/Throttling No standard - Must be part of API Management solution AUTHENTICATION Identity Management OpenID 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
- 14. 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
- 16. 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
- 18. SEC DEVOPS
- 19. 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!
- 21. 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
- 22. ENFORCE THIS COMPREHENSIVE API SECURITY POLICY 1.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
- 23. 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
- 24. 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