apidays New York 2023 - Putting yourself out there - how to secure your public APIs, Dan Erez, AT&T

apidays New York 2023
APIs for Embedded Business Models: Finance, Healthcare, Retail, and Media
May 16 & 17, 2023

Putting yourself out there - how to secure your public APIs
Dan Erez, Architecture Team Lead at AT&T

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. Putting yourself out there: Securing APIs 1 May 2023 Dan Erez
3. 2 API Conference 2023 Who am I? • Lead Architect • +20 years of software development • Native language: Java • Enterprise Architecture • Cloud Architecture • Serverless • Speaker • Trying to innovate…See in medium (dan.erez) 2
4. • API Security – Why should we care? • Some war stories • Common (and uncommon) security measures • Future of API/API security • Q&A Agenda 3 API Conference 2023
5. 4 API Security • - Any end point one can call to activate application code • - Can be M2M/S2S (Machine to Machine, Service to Service) • - Or called from a browser • - Or manually (e.g. via PostMan, Curl etc.) What do I mean when I say API? 4
6. 5 API Security API Timeline 5
7. 6 API Security • Everybody has them (MSA, legacy) • Main way to communicate (BE->BE, FE->BE) • High visibility → A wide attack surface • Not easy to defend… APIs Nowadays 6
8. 7 API Security • DDD • API = Business Service • API = Contract • Enables faster development: • Define business flows • Define interfaces • Implement API+Mock • Validate flows – do they make sense? • Check out ‘Postman Flows’ API-First Design 7
9. 8 API Security • More than 7000 applications • 2000 already moved to Azure • High degree of new connectivity (Cloud<->Cloud, Cloud<->On Prem) • Internal and External, new and upgraded APIs • ‘API Sprawl’-> less visibility, harder to manage, larger attack surface, less standardization Our Story 8
10. 9 API Security We’re on it! 9
11. 10 API Security Risks… 10 Just yesterday, T-Mobile revealed that a threat actor stole the personal information of 37 million postpaid and prepaid customer accounts via an exposed API (which they exploited between November 25, 2022 and January 5, 2023). The vendor didn’t share how the hackers exploited the API.
12. 11 API Security Risks… 11
13. 12 API Security Security Measures 12
14. 13 API Security Discovery 13 • Problem: Not all the APIs are known and classified • Shadow APIs: APIs no one knows about • Zombie APIs: Unused API • What data is being sent? • Do we want to limit users? Roles? Rate? • Solution: • Find all exposed APIs • Remove unused APIs • Document Shadow APIs • Classify the sent data
15. 14 API Security Standardization 14 Problem: • - When a company grows/transforms, standardization is harder • - Harder to maintain and protect (e.g. by applying tools) Solution: • - Define reasonable standards • - Enforce standards (using tools)
16. 15 API Security Encrypt! 15 Problem: - Old systems still use non encrypted interfaces - Or use older, less secure, standards Solution: • Apply Zero Trust standards and always encrypt • Latest TLS (1.3) • Two-way TLS (mTLS)
17. 17 API Security No General APIs! 17 Problem: - General purpose APIs expose too much data (‘getCustomers’) Solution: • - Be specific, It’s more secure (“getEnterpriseCustomers”) • No full DTOs - You’re giving away TMI
18. 18 API Security What about GraphQL? 18 Problem: • - Defaults are not secured (e.g. introspection) • - No built-in authorization mechanism • - Deep requests can take time Solution: • - Block Introspection in production • - Add authorization • - Limit size and depth
19. 19 API Security GraphQL Evil Query 19 query { repository(owner:"rails", name:"rails") { assignableUsers (first: 100) { nodes { repositories (first: 100) { nodes { assignableUsers(first: 100) { nodes { repositories(first: 100) { nodes { # Iterate until the server is exhausted } } } … One round: 5 users * 10 repositories = 50 objects Two rounds: 50 objects * 5 users * 10 repos = 2500 objects Three rounds: 2500 objects * 5 users * 10 repos = 125,000 objects Four rounds: 125000 objects * 5 users * 10 repos = 6,250,000 objects
20. 20 API Security Over privileged APIs 20 Problem: - Things change over time - Do all those users need all those permission Solution: •Automate periodic checks (Well done AT&T!) •Consider new, more specific APIs
21. 21 API Security Dos, DDos 21 Problem: • - Too many requests concurrently • - Example: AWS attack in February 2020 - 2.3 Terabits per second! - Hackers hijacked LDAP servers Solution: • - Rate Limiting (Using WAF or API Gateway) • - Limit by IP, User, API Key etc. • - CORS
22. 22 API Security OWASP is your friend! 22 Problem: • - Where should I invest my API protection energy? • - What are the common attacks? Solution: • - Check OWASP Top 10 (https://owasp.org/www- project-api-security/) • - Winners:  Broken Object Level Authorization  Broken User Authentication  Excessive Data Exposure
23. 28 API Security Tokens (JWT) 28 Problem: • - Quick and secure way to identify and authorize. • - We don’t want our user/pwd travelling all over Solution: • -Use tokens! • -OAUTH2, OIDC • -Better: Opaque tokens • atfqIQW3HXqF1hkot1e6hJDIj4qHnwTEUXiGJFf09kS RHhlx6wlDz5GZncAr99HfM7FUbDQlUg73MapL0TJ2I
24. 29 API Security Payload Challenges 29 Problem – Evil Payload: • -Very large requests • -SQL Injection • -Evil info • -Large attachments • -Viruses Solutions • -Size limiting (Payload and attachments) • -Data validation • -Virus scanning
25. 30 API Security Patch Everything… 30 Problem: • - New OS/libs vulnerabilities are found every week • - Indirectly affects your API (e.g., stolen identity) Solution: • - You can run on VMs and work hard • - Or use App Service, Kubernetes, serverless…
26. 32 API Security Monitoring & Tracking 32 Problem: • - What if something happened? • - Who did what? What data was stolen or corrupted? Solution: • - Audit! • - Track usage... and alert on suspicious usage/rate! • - Future: ML based tracking • - Train for disaster…
27. 33 API Security • One entry point! Narrow the attack surface • Easier to standardize • Great place to do some checks and rate limiting • Let developers focus on business • But – who said the attacker would pass through the Gateway? What about API Gateways? 33
28. 34 API Security • DMZ – check messages (size, sql injection etc.) – HTTP level security • Inside – Data checks API Firewalling 34
29. 35 API Security Shift Left 35
30. 36 API Security • Test, and not just functionality: • Injections • Large inputs • Revealing error messages • Some tools: Bug Bounty, Invicti, Astra Pentest, AppKnox and more • Call the pros: Professional Pen test Test/Penetrate 36
31. 37 API Security Key Takeaways 37 • Follow the latest threats • Narrow the attack surface • Use proper, updated, defenses • Penetration tests! • GOTO 10
32. 38 API Security • More ML and dynamic defenses • Automation of standards enforcement • APIOps • Let the product guys in (Entor.io) • Conversational APIs • More streaming APIs The Future of APIs 38
33. Too shy to ask here? • Dan Erez in LinkedIn • dan.erez@intl.att.com • Feel free to consult (Micro Services, Serverless, Clouds, Whatever…) Q&A & Thank you! 39 API Conference 2023