protecting your apis against attack & hijack

Download Protecting Your APIs Against Attack & Hijack

Post on 20-Aug-2015

9.610 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

  1. 1. Protecting Your APIs Against Attack and HijackK. Scott MorrisonCTOLayer 7 Technologies
  2. 2. Webinar HousekeepingQuestions-Chat any questions you have and well answer them at theend of this webinarTwitter- Todays event hashtag: #L7webinarFollow us on Twitter:- @layer7- @kscottmorrisonLayer 7 Confidential
  3. 3. Here Is What This Talk Is About: The new API threat Why is this a source of concern? Are APIs just like the Web? Or are theydifferent? Look at three important areas: 1. Parameterization 2. Identity 3. Cryptography How to apply the lessons of this talk
  4. 4. What is an API? APIServer Mobile App An API is a RESTful serviceWeb Client Web App
  5. 5. For Example: GET http://services.layer7.com/staff/Scott
  6. 6. For Example: http://services.layer7.com/staff/Scott{"firstName": Scott ","lastName" : Morrison",title": CTO,"address" :{"streetAddress": 405-1100 Melville","city": Vancouver",prov" : BC","postalCode" : V6E 4A6"},"phoneNumber":[{"type" : office","number": 605 681-9377"},{"type" : home","number": 604 555-4567"}]}
  7. 7. This is a Technological Sea ChangeOldNewTransport HTTP HTTPDataXMLJSONAuthenticationBasic, X.509,OAuthKerberos, SAMLConfidentiality & WS-SecuritySSLIntegrity
  8. 8. Where Simple WonSOAP + WS-*RESTful APIs Complex Simple Highly Informalstandardized Grassroots Vendor driven Frictionless Barriers
  9. 9. Sounds great. So whats the problem?
  10. 10. The Real Problem Is This: API Development !=Web DevelopmentIn Particular:We need to be wary of badweb development practices migrating to APIs
  11. 11. Problem Area #1: API Parameterization In the traditional web world, parameterizationwas limited and indirect Subject to the capabilities of URLs and forms APIs in contrast and offer much more explicitparameterization The full power of RESTful design: GET, POST, PUT, DELETE (And dont stop there what about effects of HEAD, etc)? This is a greater potential attack surface Injection, bounds, correlation, and so on
  12. 12. Good Web Apps Constrain Database Objects AppServer Pages HTTP Server ConstraintSpaceWeb Client
  13. 13. APIs Are A More Direct Conduit Often: Self-documenting Closely mapped to object space DatabaseApp ServerObjectsHTTPServer App
  14. 14. Consider Attack Surface
  15. 15. Script Insertion is Just One PotentialExploit2. Server fails to perform FIEO: FilterInput, Escape Output3. Browser loadsWeb App Server content with(browser+APIs)embedded script API
  16. 16. SQL Injection is AnotherExploits of a MomSource: https://xkcd.com/327/
  17. 17. Mitigation Strategy Rigorous validation of user supplied input Stronger typing Sets and ranges Avoid auto-generated schemas that make everythinga string Use schema validation XML Schema, RELAX-NG, Schematron Please no DTDs! JSON schema validation WADLs second coming
  18. 18. Mitigation Strategy (cont.) Regex scanning for signatures Tune scanning for the API Sometimes SELECT is OK Virus scanning of attachments Dont forget B64d message content Library, service, or gateway solutions Decoupled security What are the tradeoffs?
  19. 19. Mitigation Strategy Whitelist tags if you can (i.e. where the validationspace is small and concise) Not always practical (Note that Im referring to whitelisting tags not IPs.) Blacklist dangerous tags like
  20. 20. Problem Area #2: Identity We had it surprisingly good in the Web world Browser session usually tied to human Dealing with one identity is not so tough Security tokens abound, but solutions are mature Username/pass, x.509 certs, multi-factor, Kerberos, SAML, etc APIs rapidly becoming more difficult Non-human entities Multiple layers of relevant identities Me, my attributes, my phone, my developer, my provider
  21. 21. API Keys An application programing interface key (API key) is a code generated by websites that allow users to accesstheir application programming interface. API keys are usedto track how the API is being used in order to preventmalicious use or abuse of the terms of service.API keys are based on the UUID system to ensure they willbe unique to each user.(Source: wikipedia http://en.wikipedia.org/wiki/Application_programming_interface_key )
  22. 22. For Example: GET http://example.layer7.com/services/staff?APIKey=15458617-7813-4a37-94ac-a8e6da6f6405Seriously? WTF.
  23. 23. How Does An API Key Map To Identity? A person? A Or an app? 15458617-7813-4a37-94ac-a8e6da6f6405 It is entirely inconsistent
  24. 24. The Identity ProfileIncreasingly we need to move toward largenumber of claims (multiple identity profile) appID User attributes userID Roles Geo location deviceID IP User agent Time of day etc
  25. 25. Where Did API Keys Come From? API keys came from Google APIs like maps, earlyYahoo APIs, early Twitter APIs etc. Originally meant for loose, non-authoritative tracking Rate limits, approximate usage profiling Google geocoding v3.0 API deprecates API keys Uses IP instead to track and throttle This has its own set of problems IP address spoofing Problems with legitimate clients like cloud servers Google Premier uses a public client_id andrequires signed URLs (Strips domain leaving only path and query parameters)
  26. 26. The Problem with API Keys: Its a kindof like ad-hoc session tracking This is a web developer cultural issue On the web, session tokens are rarely secured Step 1: Sign in with SSL Steps 2 to n: Track session using cookie without SSL There are two bad things going on here:1. No protection of security token2. No binding of token to message content These two things are very related In 2012, this is a huge problem
  27. 27. One Word: FiresheepIn the post Firesheep world, unprotected session tracking should never be toleratedSource: http://codebutler.com/firesheep
  28. 28. Bottom Line: The API Key Was Never Meant ToBe Authoritative Strange hybrid of HTTPs USER-AGENT andsession continuity OK only for general tracking Anything that matters should use real securitytokens Anywhere where identity is important: APIs that provide access to sensitive data APIs that change things that matter APIs that charge for use etc.
  29. 29. Twitter (kind of) Gets It
  30. 30. Will OAuth survive adolescence? Complexity and confusion Interop is a nightmare right now Enterprise token management Beyond the timeout Lifecycle, revocation, distribution, etc. Talk, but not a lot of action SSL everywhere Protect bearer tokens Phishing vulnerabilities Server authentication and loss of trust in the CA infrastructure
  31. 31. Mitigation Protect the tokens!Important! HTTPS everywhere This is another web design cultural issue Its just not that expensive any more Need HTTP Strict Transport Security (HSTS) forAPIs http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
  32. 32. Problem Area #3: Cryptography and PKI Cryptography is reasonably mature on the web Surprisingly limited use patterns SSL/TLS Very little tough PKI (like client-side) So whats wrong with APIs?
  33. 33. Its Like We Forgot Everything We Knew Emailing keys API, shared secrets, etc. Bad storage schemes Security through obscurity Toy ciphers No life cycle management Limits on use Time limits Revocation Audit
  34. 34. The Issues Key management Especially across farms Nobody takes web PKI seriously CRLs and OCSP arent much good in the browserworld Fail openseriously CA trust breakdown Comodo fraud in March 2011
  35. 35. The Issues (cont.) Cipher suite restrictions Avoiding downgrades Client-side certificate authentication is hard The alternatives for parameter confidentialityand/or integrity are hard: XML encryption is still there Not for the faint of heart OAuth 1.0 gave you parameter signing Only optional in 2.0 JWT signing and encryption emerging
  36. 36. Mitigations Use real PKI I know its painful Use HSMs to protect keys that really matter Otherwise use real key material protectionschemes PKCS #12, etc Libraries abound
  37. 37. Mitigations You must do CRLs and OCSP for APIs Google maintains a certificate registry:http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html Google safe browsing API:http://code.google.com/apis/safebrowsing/developers_guide_v2.html Blacklist of phishing and malware sites DANE and DNSSEC
  38. 38. Where Does This All Leave Us? SOAP, the WS-* stack dealt with much of thisvery rigorously But it was just too hard. We need to learn from this, but make it easier toimplement Heres how
  39. 39. How Do I Apply This Today? Use SSL for all API transactions Hides many sins Confidentiality, integrity, replay, binding token+message, server authentication, etc. Use real PKI Yes, its hard But you cant skimp here Use OAuth & OpenID Connect for distributedauthentication Use real frameworks, dont reinvent They exist for most languages Consider gateways to encapsulate security
  40. 40. Solution: Layer 7 API Proxy APIGateway Cluster at Edge of NetworkServers DMZ deploymentFirewall 2 Hardware appliance, virtual appliance orsoftware Firewall 1 EnterpriseNetwork API ProxyCluster API Client
  41. 41. Solution: Layer 7 API Portal API/ServiceAPI Program ManagementServers Client-developer management Business-oriented API management DMZ deployment Virtual Appliance EnterpriseNetworkAPI Portal API Managers Client App Developers
  42. 42. Upcoming Events Tech Talk Tuesday January 29th 9am PST Bursting & Amazon Cloud Auto-scale http://layer7.com/live Valentines Special Webinar February 7th 9am PST Be My API: How to Implement an API Strategy Everyone will Love http://events.layer7tech.com/myAPI
  43. 43. For further information:K. Scott MorrisonChief Technology OfficerLayer 7 Technologies1100 Melville St, Suite 405Vancouver, B.C. V6E 4A6Canada(800) 681-9377smorrison@layer7

Recommended

View more >