Protecting Your APIs Against Attack & Hijack


Published on

Secure Enterprise APIs for Mobile, Cloud & Open Web

APIs present enterprises with many business opportunities but they also create new attack vectors that hackers can potentially exploit. APIs share many of the same threats that plague the Web but APIs are fundamentally different from Web sites and have an entirely unique risk profile that must be addressed.

By adopting a secure API architecture from the beginning, it is possible to address both old and new threats. In this webinar, Scott Morrison – CTO at Layer 7 Technologies – will explain in detail how an enterprise can pursue its API publishing strategy without compromising the security of its on-premise systems and data.

You Will Learn
How APIs increase the attack surface
What key types of risk are introduced by APIs
How enterprises can mitigate each of these risks
Why it is crucial to separate API implementation and security into distinct tiers
Presented By
Scott Morrison, CTO, Layer 7 Technologies

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Protecting Your APIs Against Attack & Hijack

  1. 1. Protecting Your APIs Against Attack and HijackK. Scott MorrisonCTOLayer 7 Technologies
  2. 2. Webinar HousekeepingQuestions-Chat any questions you have and we’ll answer them at theend of this webinarTwitter- Today’s event hashtag: #L7webinarFollow us on Twitter:- @layer7- @kscottmorrison Layer 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 they different?  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? API Server Mobile App An API is a RESTful service Web Client Web App
  5. 5. For Example: GET
  6. 6. For Example:{ "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 Change Old New Transport HTTP HTTP Data XML JSON Authentication Basic, X.509, OAuth Kerberos, SAML Confidentiality & WS-Security SSL Integrity
  8. 8. Where Simple WonSOAP + WS-* RESTful APIs• Complex • Simple• Highly • Informal standardized • Grassroots• Vendor driven • Frictionless• Barriers
  9. 9. “Sounds great. So what’s the problem?”
  10. 10. The Real Problem Is This: API Development != Web Development In Particular: We need to be wary of bad web development practices migrating to APIs…
  11. 11. Problem Area #1: API Parameterization In the traditional web world, parameterization was limited and indirect  Subject to the capabilities of URLs and forms APIs in contrast and offer much more explicit parameterization  The full power of RESTful design: GET, POST, PUT, DELETE  (And don’t 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 App Server Pages HTTP Server Constraint Space Web Client
  13. 13. APIs Are A More Direct Conduit Often: • Self-documenting • Closely mapped to object space Database App Server Objects HTTP Server App
  14. 14. Consider Attack Surface
  15. 15. Script Insertion is Just One PotentialExploit 2. Server fails to perform FIEO: Filter Input, Escape Output 3. Browser loads Web App Server content with (browser+APIs) embedded script API <SCRIPT …> 1. API injects script in Victim: Web Browser Client Attacker
  16. 16. SQL Injection is Another Exploits of a Mom Source:
  17. 17. Mitigation Strategy Rigorous validation of user supplied input  Stronger typing  Sets and ranges  Avoid auto-generated schemas that make everything a string Use schema validation  XML Schema, RELAX-NG, Schematron  Please no DTDs!  JSON schema validation  WADL’s second coming
  18. 18. Mitigation Strategy (cont.) Regex scanning for signatures Tune scanning for the API  Sometimes SELECT is OK Virus scanning of attachments  Don’t forget B64’d 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 validation space is small and concise)  Not always practical  (Note that I’m referring to whitelisting tags not IPs.) Blacklist dangerous tags like <SCRIPT> Always perform FIEO (Filter Input, Escape Output) Learn more:
  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 used to track how the API is being used in order to prevent malicious use or abuse of the terms of service.API keys are based on the UUID system to ensure they will be unique to each user.”(Source: wikipedia )
  22. 22. For Example: GET ?APIKey=15458617-7813-4a37-94ac-a8e6da6f6405 Seriously? 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, early Yahoo 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 and requires signed URLs  (Strips domain leaving only path and query parameters)
  26. 26. The Problem with API Keys: It’s 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 token 2. No binding of token to message content These two things are very related In 2012, this is a huge problem…
  27. 27. One Word: Firesheep In the post Firesheep world, unprotected session tracking should never be tolerated…Source:
  28. 28. Bottom Line: The API Key Was Never Meant ToBe Authoritative Strange hybrid of HTTP’s USER-AGENT and session continuity OK only for general tracking Anything that matters should use real security tokens  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  It’s just not that expensive any more Need HTTP Strict Transport Security (HSTS) for APIs  ecurity
  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 what’s wrong with APIs?
  33. 33. It’s 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 aren’t much good in the browser world  Fail open—seriously 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 confidentiality and/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 it’s painful Use HSMs to protect keys that really matter Otherwise use real key material protection schemes  PKCS #12, etc  Libraries abound
  37. 37. Mitigations You must do CRLs and OCSP for APIs Google maintains a certificate registry: /improving-ssl-certificate-security.html Google safe browsing API: opers_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 this very rigorously  But it was just too hard. We need to learn from this, but make it easier to implement Here’s 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, it’s hard  But you can’t skimp here Use OAuth & OpenID Connect for distributed authentication Use real frameworks, don’t reinvent  They exist for most languages  Consider gateways to encapsulate security
  40. 40. Solution: Layer 7 API Proxy APIGateway Cluster at Edge of Network Servers DMZ deployment Firewall 2 Hardware appliance, virtual appliance or software Firewall 1 … Enterprise Network API Proxy Cluster API Client
  41. 41. Solution: Layer 7 API Portal API/ServiceAPI Program Management Servers Client-developer management Business-oriented API management DMZ deployment Virtual Appliance … Enterprise Network API Portal API Managers Client App Developers
  42. 42. Upcoming Events Tech Talk Tuesday January 29th – 9am PST Bursting & Amazon Cloud Auto-scale Valentines Special Webinar February 7th – 9am PST Be My API: How to Implement an API Strategy Everyone will Love
  43. 43. For further information: K. Scott Morrison Chief Technology Officer Layer 7 Technologies 1100 Melville St, Suite 405 Vancouver, B.C. V6E 4A6 Canada (800) 681-9377