Best Practices You Must Apply to Secure Your APIs - Scott Morrison, SVP & Distinguished Engineer, CA Technologies @ Cloud Identity Summit
 

Best Practices You Must Apply to Secure Your APIs - Scott Morrison, SVP & Distinguished Engineer, CA Technologies @ Cloud Identity Summit

on

  • 2,818 views

By now you’ve bought into the idea of using APIs to integrate cloud, mobile devices and the enterprise. But are building safe APIs? One insecure API can increase your organization’s risk profile ...

By now you’ve bought into the idea of using APIs to integrate cloud, mobile devices and the enterprise. But are building safe APIs? One insecure API can increase your organization’s risk profile exponentially. Securing APIs is not like securing the web—a point lost on many developers coming from a web-centric background. Learn what good practices to put in place and the common security anti-patterns you must avoid to ensure your company’s APIs are reliable, safe and secure. You will learn:
• The top ways hackers exploit APIs in the wild
• Common identity pitfalls and how to avoid them
• Why OAuth scopes are essential to master
• How to keep web developers from bringing bad habits with them

Statistics

Views

Total Views
2,818
Views on SlideShare
779
Embed Views
2,039

Actions

Likes
4
Downloads
29
Comments
1

6 Embeds 2,039

http://www.scoop.it 2027
https://twitter.com 6
http://www.slideee.com 2
http://webcache.googleusercontent.com 2
http://www.google.com 1
http://news.google.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Nice Work Mr.Scott
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Spoke with Ramon Kirkan yesterday. Sometimes its OK to not decouple. <br /> Ask app what it wants to be
  • Note use of “users” here

Best Practices You Must Apply to Secure Your APIs - Scott Morrison, SVP & Distinguished Engineer, CA Technologies @ Cloud Identity Summit Best Practices You Must Apply to Secure Your APIs - Scott Morrison, SVP & Distinguished Engineer, CA Technologies @ Cloud Identity Summit Presentation Transcript

  • Best Practices You Must Apply to Secure Your APIs K. Scott Morrison SVP and Distinguished Engineer
  • © 2014 CA. ALL RIGHTS RESERVED. Here Is What This Talk Is About:  The new API threat – …and the potential rise of the hacker-robber-baron  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
  • © 2014 CA. ALL RIGHTS RESERVED. What is an API? Web App API Server Web Client Mobile App An API is a RESTful service
  • © 2014 CA. ALL RIGHTS RESERVED. For Example: GET http://services.layer7.com/staff/Scott
  • © 2014 CA. ALL RIGHTS RESERVED. 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" } ] } http://services.layer7.com/staff/Scott
  • © 2014 CA. ALL RIGHTS RESERVED. “Sounds great. So what’s the problem?” API Development != Web Development In Particular: We need to be wary of bad web development practices migrating to APIs…
  • © 2014 CA. ALL RIGHTS RESERVED. 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 creates a greater potential attack surface – Injection, bounds, correlation, and so on
  • © 2014 CA. ALL RIGHTS RESERVED. Good Web Apps Constrain HTTP Server App Server Database Web Client Objects Pages Constraint Space Records
  • © 2014 CA. ALL RIGHTS RESERVED. APIs Are A More Direct Conduit HTTP Server App Server Database App Objects Often: • Self-documenting • Closely mapped to object space, data structure, etc APIs can leak information
  • © 2014 CA. ALL RIGHTS RESERVED. APIs Also Increase Attack Surface
  • © 2014 CA. ALL RIGHTS RESERVED. Attacker Web App Server (browser+APIs) Victim: Web Browser Client <SCRIPT …> 1. API injects script in 3. Browser loads content with embedded script 2. Server fails to perform FIEO: Filter Input, Escape Output API Script Insertion is Just One Potential Exploit
  • © 2014 CA. ALL RIGHTS RESERVED. SQL Injection is Another Source: https://xkcd.com/327/ Exploits of a Mom
  • © 2014 CA. ALL RIGHTS RESERVED. Mitigation Strategy  Rigorous validation of consumer supplied inputs – and API output! – Stronger typing – Sets and ranges – Avoid auto-generated schemas that make everything a string  Use schema validation – XML Schema, RELAX-NG, Schematron – Pick your poison  Please no DTDs! – JSON schema validation – Return of IDLs: WADL, RAML, Swagger, etc  Be strict with handling Content-Type and Accept headers Constrain by Default
  • © 2014 CA. ALL RIGHTS RESERVED. Mitigation Strategy (cont.)  Regex scanning for signatures  Tune patterns for the API – Sometimes SELECT is OK  Virus scanning of attachments – Don’t forget B64’d message content  Constrain HTTP methods – Does your API need HEAD?  Constrain URI context – Don’t let people get creative and fuzz URIs – Authorize templates  Don’t treat APIs in isolation – HTTP may be stateless, but your call sequence may not be  Beware of dangerous hidden shortcuts in the later
  • © 2014 CA. ALL RIGHTS RESERVED. Mitigation Strategy (cont.)  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)  Watch for generalized parameter fuzzing – This is a trend—not an event!  Be careful with error messages and leakage – Don’t reveal too much info
  • © 2014 CA. ALL RIGHTS RESERVED. 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…
  • © 2014 CA. ALL RIGHTS RESERVED. API Keys “An application programing interface key (API key) is a code generated by websites that allow users to access their 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 http://en.wikipedia.org/wiki/Application_programming_interface_key )
  • © 2014 CA. ALL RIGHTS RESERVED. For Example: GET http://example.layer7.com/services/staff ?APIKey=15458617-7813-4a37-94ac-a8e6da6f6405 Seriously? WTF.
  • © 2014 CA. ALL RIGHTS RESERVED. How Does An API Key Map To Identity? 15458617-7813-4a37-94ac-a8e6da6f6405 A A person? Or an app? It is entirely inconsistent
  • © 2014 CA. ALL RIGHTS RESERVED. Bottom Line: The API Key Was Never Meant To Be 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.
  • © 2014 CA. ALL RIGHTS RESERVED. Mitigation
  • © 2014 CA. ALL RIGHTS RESERVED. The Identity Profile Increasingly we need to move toward large number of claims (multiple identity profile) • appID • userID • deviceID • User attributes • Roles • Geo location • IP • User agent • Time of day • etc
  • © 2014 CA. ALL RIGHTS RESERVED. Mitigation (cont.)  Protect the tokens!  HTTPS everywhere – This is another web design cultural issue – It’s just not that expensive any more  OAuth for people  APIKeys for apps – Assume this is non-authoritative  Consider behavioral identification of apps – Apps are rigid in their API flow Important!
  • © 2014 CA. ALL RIGHTS RESERVED. 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?
  • © 2014 CA. ALL RIGHTS RESERVED. 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
  • © 2014 CA. ALL RIGHTS RESERVED. The Issues  Key management – Across server farms, across client devices  Nobody takes web PKI seriously – CRLs and OCSP aren’t much good in the browser world  Fail open—seriously  CA trust breakdown – Indian NIC issue July 2014  Subordinate CA issued fraudulent Google and Yahoo certs
  • © 2014 CA. ALL RIGHTS RESERVED. 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
  • © 2014 CA. ALL RIGHTS RESERVED. SSL Everywhere (it’s cheap)
  • © 2014 CA. ALL RIGHTS RESERVED. Mitigations  Use real PKI – I know it’s painful  Use HSMs to protect keys that really matter  Recognize OAuth limitations in browser-resident JavaScript apps – No shared secrets – Stuck with OAuth 2.0 implicit grant  Otherwise use real key material protection schemes – PKCS #12, etc – Libraries abound  You must do CRLs and OCSP for APIs
  • © 2014 CA. ALL RIGHTS RESERVED. 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…
  • © 2014 CA. ALL RIGHTS RESERVED. 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 for distributed authentication  Validate all data going in and out of an API  Use real frameworks, don’t reinvent
  • SVP and Distinguished Engineer Scott.Morrison@ca.com @KScottMorrison http://KScottMorrison.com linkedin.com/KScottMorrison ca.com K. Scott Morrison