(Mis)Using APIs for Fun & Profit

Over the last decade, APIs have opened up new worlds and allowed us to accomplish wildly complex tasks with just a few lines of code. They’ve made the extraordinary almost mundane. Unfortunately, poorly designed and implemented APIs have opened us up to vulnerabilities and attacks we never considered before. While Equifax is the biggest and one of the most well known, odds are there are APIs within your systems which are just as bad but you don’t even know.

In this session, we’ll walk through a number of (now resolved!) vulnerabilities from production APIs, how they were found, and what you should watch for in your own APIs.

Transcript

1. (MIS)USING & ABUSING APIS D. Keith Casey Jr keith@caseysoftware.com @CaseySoftware
2. WHO AM I?
3. WHO AM I?
4. WHO AM I?
5. IT’S UGLY OUT THERE
6. CAMBRIDGE ANALYTICS • Not a data breach, not even misuse • They used it exactly as Facebook planned, designed, and implemented • Just as thousands of others have
7. EQUIFAX • Actually, wait.. let’s come back to this one.
8. PANERA • Completely unprotected API • Reported in August 2017, not addressed until April 2018 • Gave access to name, address, email, username, phone, birthday, food preferences, and last 4 credit card digits
9. WHAT CAN I DO WITH THIS? • Change your food preferences? • Verify your email address/phone number? • Use your home address? • Hijack your Google & Twitter accounts and get control of your Mac?
10. ATTACK PATTERN • Use Panera data to get name, email, address and last 4 cc digits • Contact Tech Support to update email address, reset accounts, take over everything • Contact [cell carrier] to port number to compromise 2FA-protected systems & data
11. Credit: https://medium.com/@djhoulihan/no-panera-bread-doesnt-take-security-seriously-bf078027f815
12. EQUIFAX
13. EQUIFAX • Identity Proofing • When you sign up for something and have to verify who you are • Realistically, this no longer exists. With this data, anyone can “prove” they are anyone they want
14. HOW DID WE GET HERE?
15. API JOURNEY: A MATURITY MODEL 5 Phase 0 Integrate internal systems by introducing Private APIs Phase 1 Internal advocacy & collaboration for internal APIs and CoE/ Governance Phase 2 Limited API access to partners, resellers and suppliers Phase 3 Grow these APIs as full fledged products with external developer access Either monetized directly or to reach new customers and enter new markets. Security Team evaluates use cases, interfaces, authentication, access management, etc, etc Credit: okta.com
16. API JOURNEY: A MATURITY MODEL 6 Phase 0 Integrate internal systems by introducing Private APIs Phase 1 Internal advocacy & collaboration for internal APIs and CoE/ Governance Phase 2 Limited API access to partners, resellers and suppliers Phase 3 Grow these APIs as full fledged products with external developer access Either monetized directly or to reach new customers and enter new markets. The security issue was always there Credit: okta.com
17. THREE GROUPS: ALWAYS AT WAR ODDS Buyers: Integration Architects (NEW) Influencers: Developers Security Architects Credit: okta.com
18. SO WHAT DO WE DO?
19. AuthN vs AuthZ • Authentication is “who you are” • Authorization is “what are you allowed to do” • Understand who needs to do what when • is_admin is NOT enough
20. • Scope your API keys • Expire/rotate your keys • Provide multiple keys? • Understand the use cases you’re addressing KEY & TOKEN MGMT
21. • What does sample code demonstrate? • What the API does • How to use the API • The Right Way to use the API WRITE GOOD EXAMPLES
22. WHAT DO WE AVOID?
23. Don’t: Roll your own Encryption • Use an existing library that implements an open standard, audit if you prefer • Don’t create your own encryption • No, don’t. You’re not special. • No, not even then. Are you even listening?
24. Don’t: Leak your own Data • What can I tell from using your API? • Do the URLs tell a story? • Does that put customers at risk? • Does it share internal company data?
25. Don’t: Collect or Share Extra Data • Cambridge Analytica • Why should people to share this information? • How might Keith a bad actor use this information? • You can’t leak what you don’t have
26. SO WHAT IF I DON’T?
27. WHY?
28. (MIS)USING & ABUSING APIS D. Keith Casey Jr keith@caseysoftware.com @CaseySoftware