The document discusses API security fundamentals and how to effectively secure APIs. It notes that many past API breaches were due to a lack of authentication on APIs, no rate limiting of requests, and other basic security issues. It emphasizes that every system with a URI has an API and outlines steps like applying authentication, authorization, rate limiting, validating requests to prevent attacks. The document argues that APIs with well-defined contracts that specify URIs, input/output formats and authentication models are easier to securely implement and test compared to more complex, dynamic APIs.
8. Everything with a URI has an API
Of Course You Have an API!
8
Wired, 9/22/15
www.ifc0nfig.com, 1/5/15
troyhunt.com, 2/24/16
9. 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
Some API Security Breaches
10. • No authentication on some APIs
– Climate control, battery status
– Only VIN number required
• User ID leaked by some of those APIs
http://www.troyhunt.com/2016/02/controlling-vehicle-features-of-nissan.html
Nissan Leaf
11. • No rate limit on request to get friends by phone
number
• Hard-coded encryption key
• Weak cipher
http://gibsonsec.org/snapchat/
Snapchat
14. • Prevent unauthorized applications
• Prevent unauthorized users
• Prevent excessive traffic
• Prevent content attacks
• Watch for trouble
• React to trouble
What You Need to Do
15. What Do Our Customers Do?
74%
OAuth
78%
Spike
Arrest
72%
Threat
Protection
16. • 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
Prevent Unauthorized Applications
17. • 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?
Prevent Unauthorized Users
18. • 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
Prevent Excessive Traffic
19. • 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
Prevent Content Attacks
20. • Monitor the API
– Usage patterns
– Usage patterns by application
– Latency
– Error rate
• Monitor the world too
– Unusual tweets?
– Other social media?
Watch for Trouble
21. • 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
Example: Bot Detection
22. • 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
React to Trouble
26. • Simple
• Ubiquitous
• Widely-understood
• Universally implemented
The “API Stack” is Small
27. • 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
API Contracts are Simple
28. • 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
Simpler Means More Secure
29. • Well-known URI pattern
• Documented schemas
• Well-known authentication model
• Well-known authorization model
• One way to secure all API calls
Simpler is Better
• 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
31. • 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!
Conclusion