Presentation from Apigee's Open Banking & PSD2 Summit in London on 19th May 2016. This presentation covers Apigee's innovative data driven security approach that detects intelligent bots, transaction anomalies, and helps protect your APIs from cyberthreats.
6. Of Course You Have an API!
6
Wired, 9/22/15
www.ifc0nfig.com, 1/5/15
troyhunt.com, 2/24/16
Everything with a URI has an API
7. Some API Security Breaches
Breach Reason Source
Buffer Compromised third-party admin password;
OAuth secret in GitHub
ProgrammableWeb
Snapchat No authentication; no rate limit Gibson Security
Multiple Kardashian
Apps
No authentication or authorization Wired
MoonPig No authentication or authorization www.ifc0nfig.com
Facebook Graph API Users can delete other users’ photos; Improper
authorization check
ProgrammableWeb
IRS GetTranscript
Application
Password reset mechanism relied on personal
data
IRS
Instagram Malicious app was stealing passwords; no
approval process
Daily Dot
Nissan Leaf VIN number only security credential on API Troy Hunt
Tesla Model S Six-character password that’s easily guessable Security Affairs,
Elsewhere
9. • No rate limit on request to get friends by phone number
• Hard-coded encryption key
• Weak cipher
• http://gibsonsec.org/snapchat/
Snapchat
10. Mobile Banking Apps
• Security researcher Ariel Sanchez examined 20 iOS
banking apps from banks around the world
• More than 30% used non-TLS-encrypted links for
at least part of the app
• Down from 90% two years ago
• Demonstrated JavaScript interception of some
apps’ “login” page to gather passwords
10
Ariel Sanchez, blog.ioactive.com
11. A South Asian Bank
• Security researcher Sathya Prakash tested the security of the app
he used for one of his bank accounts
• Found many major flaws and one huge one
• All validation of account numbers for funds transfers was performed
in the mobile app only – not on the server
11
12. SWIFT
• Over $900 million in fraudulent transfer requests due to compromise at a member bank
• Became $81 million due to a typo
BAE Systems Applied Intelligence
14. APIs for Controlled
Access
• APIs provide a controlled way for third parties to access a
service
• Not having an API means that third parties will find another
way
• That’s why JPMC is considering this:
15. Federated Security is a Must
Systems like OAuth and OpenID exist for
the purpose of managing secure access
without sharing passwords
-- JPMorgan Chase, 2015 letter to shareholders
16. Trusted Endpoints Aren’t
• API security must assume untrusted endpoints
• User authentication
• Fraud detection
• Application-level authentication
19. What You Need to Do
• Prevent unauthorized applications
• Prevent unauthorized users
• Prevent excessive traffic
• Prevent content attacks
• Watch for trouble
• React to trouble
20. What Do Apigee Customers Do?
74%
OAuth
78%
Spike
Arrest
72%
Threat
Protection
21. What do Others Do?
• A wide variety of solutions out there
• 87% percent have “API management”
• 83% are “concerned” about API security
22. Prevent Unauthorized Applications
• Application Authorization is a fundamental part of API security
• Best way to stop runaway applications
• Only options for certain types of apps (anonymous API access)
• Requirement for all forms of OAuth
• Best practices
• Use different credentials for each version of each app
• Makes it easier to pull a bad version
• Hide the app credentials as best you can
• Realize that they still can be stolen
• Have an approval process for apps
23. Prevent Unauthorized Users
• Authenticate all end users for critical apps
• Only way to keep security credentials outside the app
• Use OAuth carefully
• Use caution around “password” grant type
• Only as good as identity management
• For instance, dodgy password reset practices
• Can you get identity a service?
24. Don’t Make It Up
• OAuth 1.0: Bug
• OAuth 1.0a: Better
• OAuth 2.0 authorization code grant type: Attack identified
• RFC 7636 (PKCE) fixes it
• Would you have discovered this on your own?
25. Prevent Excessive Traffic
• Protect APIs that are vulnerable to brute force
• Validating password
• Validating anything
• Anything where the only ID is in a small space
• Protect from runaway applications
• Denial of service is also an attack
• Excessive usage may mean data is being harvested
• Not always an attack – developers make mistakes
26. Prevent Content Attacks
• Accepting JSON over the Internet?
• Excessive identifier length
• Excessive nesting
• Large arrays and elements
• Accepting XML over the Internet?
• All that and more
• Are you sure there can’t be SQL injection?
• Regular expression checks
27. Watch for Trouble
• Monitor the API
• Usage patterns
• Usage patterns by application
• Latency
• Error rate
• Monitor the world too
• Unusual tweets?
• Other social media?
28. Example: Bot Detection
• Traffic comes from unusual places:
• iPads in Amazon data centers
• US-only retailers with many “customers” in Eastern
Europe
• Or unusual patterns:
• Sequential scans of identifiers
• API traffic faster than a human can generate
• Identify suspected “bots”
• Heuristics, machine learning
• Block them by IP or otherwise
29. React to Trouble
• Do you have application-level authentication?
• Revoke app credentials
• Change rate limit
• Redirect app to another URL
• No application-level authentication?
• Insert additional logic
• Worst cast: shut down the API until it’s
fixed
33. The “API Stack” is Small
• Simple
• Ubiquitous
• Widely-understood
• Universally implemented
34. API Contracts are Simple
• Since API technology is simple,
• So is the contract:
• URIs
• JSON schemas
• Query parameters
• Authentication
• Simpler contracts are:
• simpler to validate
• simpler to test
• simpler to prove
35. Simpler Means More Secure
• Don’t agree? Let’s look at web apps:
• Cross-site scripting
• Insecure URIs in links
• Cross-site request forgery
• Insecure redirects
• Insecure third-party pages
• Insecure and malicious JavaScript
36. Simpler is Better
• Well-known URI pattern
• Documented schemas
• Well-known authentication model
• Well-known authorization model
• One way to secure all API calls
• Totally dynamic URI pattern is harder to
test
• Specified inputs and outputs can be
tested
• Haphazard authentication hard to test
• Haphazard authorization hard to test
• Multiple implementations hard to test
37. Summing it Up
APIs are essentail for security’
Security is essential to APIs’
APIs risk is well-understood.
38. Conclusion
• We saw lots of places where APIs were compromised
• Many of these had nothing to do with an “API”
• Biggest vulnerability is having an API and not realizing it
• Everything with a URL has an API
• Well-defined APIs can be secured
• Lots of widely-known techniques and technology
• A properly-secured API is verifiable
• Use it!