Ad
More Related Content
What's hot (20)
Similar to Peeling the Onion: Making Sense of the Layers of API Security (20)
Ad
More from Matt Tesauro (20)
Ad
Recently uploaded (20)
Peeling the Onion: Making Sense of the Layers of API Security
- 1. Peelingthe Onion Making Sense of the Layers of API Security
- 2. Tableofcontents Overview Quick overview of APIs in general 01 APISecurity Overview of API Security 02 APISecurityLandscape All the parts that make up the API ecosystem 03 APISecurityConcerns Items to consider when securing your API 04 Conclusion Key Takeaways 05
- 3. Overview 01 Quick overview of APIs in general
- 4. APISecurity I believe that API Security is different enough from ‘traditional’ AppSec that it needs special attention. I also believe that API use is only going to grow over time.
- 5. Who’sthisguy? ● Reformed programmer & AppSec Engineer ● Noname Security - Distinguished Engineer, Noname Labs ● 14 years in the OWASP community ○ OWASP DefectDojo (core maintainer) ○ OWASP AppSec Pipeline (co-leader) ○ OWASP WTE (leader) ● 22+ years using FLOSS and Linux ● Currently a Go language fanboy ● Ee Dan in Tang Soo Do Mi Guk Kwan (2nd degree black belt) ● Founder 10Security
- 6. APIs areSimple… Wikipedia: An application programming interface (API) is a connection between computers or between computer programs.
- 7. APIs aresimplynotSimple XML-RPC, SOAP REST, gRCP, GraphQL Type Data Encoding: XML, JSON, binary (protobuf, thrift, …) INfra Transport HTTP(S), HTTP/2, HTTP/3, QUIC Load balancer, API Gateway, Control plane ● Product Teams ● Developers ● Network Admins ● InfoSec / AppSec ● API Gateway Admins ● Security Operations (SOC/IR) ● Mobile Teams Stakeholders
- 9. APIBreadth anddepth Over time your APIs will grow: ● Breadth growth More and more API endpoints get added ● Depth growth APIs calls create calls to other APIs, rinse & repeat, especially for microservices
- 10. CardinalDirections& APIs North/South traffic ● Traffic from the client to an API usually through an API gateway ● Originates outside the ‘data center’ or VPC e.g. external East/West traffic ● Traffic between internal APIs frequently bypassing an API gateway ● Originates inside the ‘data center’ or VPC e.g. internal
- 11. A BetterDefinitionof an API From a security controls point of view, an API is really a combination of: ● Method ○ GET, POST, PUT, … ● Hostname ○ example.com ● Path ○ /v2/users/all GET to example.com/v2/users/all!= DELETE to example.com/v2/users/all POST to uat.example.com/v2/user/admin!= POST to example.com/v2/user/admin
- 12. APISecurity 02 Overview of API Security
- 14. APISecurityDefined For the purposes of this talk: API Security includes determining the state of security from the perspectives of: ● API Security Posture ● API Runtime Security ● API Security Testing (hopefully continuous)
- 15. APISecurityPosture Getting a broad, holistic view of your API landscape including: ● An inventory of every API (the security control definition) ○ Those going through an API gateway ○ Those not going through an API gateway / legacy ○ Internal APIs (east/west) ● Mapping of data going to and from the APIs ○ Classify data traversing the APIs ● Who, What, from Where ○ Who is calling the API? ○ What data are they sending/receiving? ○ Where did the call originate?
- 16. APIRuntimeSecurity Understanding the ‘normal’ operations of running APIs including: ● Watching / inspecting traffic to and from the API ○ Inline or out of band ○ Understand all types (REST, gRPC, GraphQL, …) ● Creating behavior based models of traffic for anomaly detection ○ Heuristic, ML, ‘AI’ modeling ○ Continual learning methods ● Thresholds for abnormal traffic, triggering alerts ○ Policies on sensitive or large volumes of data ○ Respond to alerts, manual, semi-auto or automatically ○ Blocking, geo-fencing, deny external traffic
- 17. APITesting Assess the security state of a running API ● DAST not SAST ○ SAST isn’t API specific so out of scope ○ Bonus points for continuous or CI/CD friendly ● Understand the APIs available methods ○ Swagger/OpenAPI spec files ○ Recorded traffic (http or other) ○ Automatic understanding based on traffic +1 ● Forwarding results to the right people ○ Issue tracker integrations e.g. Jira ○ Ability to see vulnerable requests/responses ○ Ability to re-test specific issue
- 18. APISecurity Landscape 03 All the parts that make up the API ecosystem
- 19. All the world’s a stage, and all the men and women merely players API stakeholders Wait, what?
- 20. Settingthestage
- 21. Breakingdownthelandscape WAF Stakeholders: Network Ops, AppSec, Product Teams, … Web App Stakeholders: Product Teams, AppSec, Marketing, … Mobile App Stakeholders: Mobile & Product Teams, AppSec, …
- 22. Breakingdownthelandscape IdP Stakeholders: Identity and Access, AppSec, InfoSec, … APIGateway Stakeholders: Gateway Admins, Product, AppSec, … APIs Stakeholders: Product Teams, AppSec, Marketing, …
- 23. Breakingdownthelandscape Cloud Stakeholders: Cloud Team, Product, AppSec, Finance, … SOC Stakeholders: IR Team, Product Team, InfoSec / AppSec, …
- 24. APISecurity Concerns 04 Items to consider when securing your API
- 26. AttackClasses DDOS - Distributed Denial Of Service ● Network DDOS ○ Traditional flood of traffic ○ Controls are fairly standardized ● HTTP Flood ○ Uses HTTP methods (GET, POST, …) ○ Mirrors legit traffic ○ Single client/customer ‘over consuming’ ● Application DOS ○ Consumption attacks (CPU, RAM, …) ○ Can be single or few requests ○ Lack of pagination Posture RUntime Testing
- 27. AttackClasses Data breach / leak attacks ● Internal services made public ○ Misconfiguration / Lack of API Gateway ○ Lack of Policy enforcement ● Excessive data exposure ○ Verbose API responses ○ Return full data objects, clients ‘filter’ ○ Injection attacks ● Auth-n and Auth-Z weakness ○ Allows account/token takeover ○ BOLA - Client can request others’ data Posture RUntime Testing
- 28. AttackClasses Abuse of Functionality ● Business Logic Flaws ○ Normal use-case, unintended use ○ Attackers use your API for their purpose ○ Automatic testing won’t find these ● Examples ○ Spamming using your API ○ Denial of Inventory - products in a cart ○ Carding - validate stolen card data ○ Ad Fraud / Evil SEO ● See “OWASP Automated Threat Handbook” Posture RUntime Testing
- 29. OWASP APITop10 Risk Posture Runtime Testing 01: Broken Object Level Authorization 02: Broken User Authentication 03: Excessive Data Exposure 04: Lack of Resource & Rate Limiting 05: Broken Function Level Authorization
- 30. OWASP APITop10 Risk Posture Runtime Testing 06: Mass Assignment 07: Security Misconfiguration 08: Injection 09: Improper Assets Management 10: Insufficient Logging & Monitoring
- 32. APIstakeholderSoup Product Team AppSec Onion Network Ops Mobile Team InfoSec IAM Team
- 33. Key Takeaways Complexity APIs seem simple on the surface but quickly become a complex collections of systems with many moving parts Perspectives API security has many perspectives which need to be taken into account when evaluating an API security program Coordination Beyond the multiple IT systems, secure APIs require tight coordination between many different teams Multifaceted Protecting APIs includes evaluation from the perspective of security posture, runtime security and testing
- 34. CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon and infographics & images by Freepik THANKS! Doyouhave anyquestions? [email protected] https://www.linkedin.com/in/matttesauro/ @matt_tesauro