CIS14: Best Practices You Must Apply to Secure Your APIs
2 likes680 views
The document discusses best practices for securing APIs, highlighting new threats, differences between API and web development, and critical areas such as parameterization, identity management, and cryptography. It emphasizes the importance of rigorous input validation, using real security tokens, and securing communications with SSL. The speaker advocates for the use of OAuth for user authentication and stresses the need for robust data handling and key management strategies.
![©
2014
CA.
ALL
RIGHTS
RESERVED.
For
Example:
{
"firstName":
”Sco^
",
"lastName"
:
”Morrison",
”+tle"
:
“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](https://image.slidesharecdn.com/edemwvq0yne9vc3niw2q-signature-e77353a5531666e85fadeb0e4ebdcbd4e7522e2f525b50388570d11bd88051f3-poli-140804140914-phpapp02/85/CIS14-Best-Practices-You-Must-Apply-to-Secure-Your-APIs-5-320.jpg)
CIS14: Best Practices You Must Apply to Secure Your APIs
- 1. Best Prac*ces You Must Apply to Secure Your APIs K. Sco7 Morrison SVP and Dis+nguished Engineer
- 2. © 2014 CA. ALL RIGHTS RESERVED. Here Is What This Talk Is About: § The new API threat – …and the poten+al rise of the hacker-‐robber-‐baron § Are APIs just like the Web? Or are they different? – Look at three important areas: 1. Parameteriza+on 2. Iden+ty 3. Cryptography § How to apply the lessons of this talk
- 3. © 2014 CA. ALL RIGHTS RESERVED. What is an API? Web App API Server Web Client Mobile App An API is a RESTful service
- 4. © 2014 CA. ALL RIGHTS RESERVED. For Example: GET http://services.layer7.com/staff/Scott
- 5. © 2014 CA. ALL RIGHTS RESERVED. For Example: { "firstName": ”Sco^ ", "lastName" : ”Morrison", ”+tle" : “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
- 6. © 2014 CA. ALL RIGHTS RESERVED. “Sounds great. So what’s the problem?” API Development != Web Development In Par*cular: We need to be wary of bad web development prac=ces migra=ng to APIs…
- 7. © 2014 CA. ALL RIGHTS RESERVED. Problem Area #1: API Parameteriza=on § In the tradi+onal web world, parameteriza+on was limited and indirect – Subject to the capabili+es of URLs and forms § APIs in contrast and offer much more explicit parameteriza+on – 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 poten+al a^ack surface – Injec+on, bounds, correla+on, and so on
- 8. © 2014 CA. ALL RIGHTS RESERVED. Good Web Apps Constrain HTTP Server App Server Database Web Client Objects Pages Constraint Space Records
- 9. © 2014 CA. ALL RIGHTS RESERVED. APIs Are A More Direct Conduit HTTP Server App Server Database App Objects OIen: • Self-‐documen+ng • Closely mapped to object space, data structure, etc APIs can leak informa*on
- 10. © 2014 CA. ALL RIGHTS RESERVED. APIs Also Increase A7ack Surface
- 11. © 2014 CA. ALL RIGHTS RESERVED. A^acker Web App Server (browser+APIs) Vic+m: 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 Inser*on is Just One Poten*al Exploit
- 12. © 2014 CA. ALL RIGHTS RESERVED. SQL Injec+on is Another Source: h^ps://xkcd.com/327/ Exploits of a Mom
- 13. © 2014 CA. ALL RIGHTS RESERVED. Mi*ga*on Strategy § Rigorous valida+on of consumer supplied inputs – and API output! – Stronger typing – Sets and ranges – Avoid auto-‐generated schemas that make everything a string § Use schema valida+on – XML Schema, RELAX-‐NG, Schematron – Pick your poison § Please no DTDs! – JSON schema valida+on – Return of IDLs: WADL, RAML, Swagger, etc Constrain by Default
- 14. © 2014 CA. ALL RIGHTS RESERVED. Mi*ga*on Strategy (cont.) § Regex scanning for signatures § Tune pa^erns for the API – Some+mes SELECT is OK § Virus scanning of a^achments – Don’t forget B64’d message content § Library, service, or gateway solu+ons – Decoupled security – What are the tradeoffs?
- 15. © 2014 CA. ALL RIGHTS RESERVED. Mi*ga*on Strategy (cont.) § Whitelist tags if you can (i.e. where the valida+on space is small and concise) – Not always prac+cal – (Note that I’m referring to whitelis+ng tags not IPs.) § Blacklist dangerous tags like <SCRIPT> § Always perform FIEO (Filter Input, Escape Output) § Watch for fuzzing – This is a trend—not an event! § Learn more: h^p://xssed.com
- 16. © 2014 CA. ALL RIGHTS RESERVED. Problem Area #2: Iden=ty § We had it surprisingly good in the Web world – Browser session usually +ed to human – Dealing with one iden+ty is not so tough § Security tokens abound, but solu+ons are mature – Username/pass, x.509 certs, mul+-‐factor, Kerberos, SAML, etc – APIs rapidly becoming more difficult § Non-‐human en++es § Mul+ple layers of relevant iden++es – Me, my a^ributes, my phone, my developer, my provider…
- 17. © 2014 CA. ALL RIGHTS RESERVED. API Keys “An applica*on programing interface key (API key) is a code generated by websites that allow users to access their applica+on 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 h^p://en.wikipedia.org/wiki/Applica+on_programming_interface_key )
- 18. © 2014 CA. ALL RIGHTS RESERVED. For Example: GET http://example.layer7.com/services/staff ?APIKey=15458617-‐7813-‐4a37-‐94ac-‐a8e6da6f6405 Seriously? WTF.
- 19. © 2014 CA. ALL RIGHTS RESERVED. How Does An API Key Map To Iden+ty? 15458617-‐7813-‐4a37-‐94ac-‐a8e6da6f6405 A A person? Or an app? It is en+rely inconsistent
- 20. © 2014 CA. ALL RIGHTS RESERVED. The Iden+ty Profile Increasingly we need to move toward large number of claims (mul+ple iden+ty profile) • appID • userID • deviceID • User attributes • Roles • Geo location • IP • User agent • Time of day • etc
- 21. © 2014 CA. ALL RIGHTS RESERVED. Where Did API Keys Come From? § API keys came from Google APIs like maps, early Yahoo APIs, early Twi^er APIs etc. – Originally meant for loose, non-‐authorita+ve tracking – Rate limits, approximate usage profiling § Google geocoding v3.0 API deprecates API keys – Uses IP instead to track and thro^le – This has its own set of problems § IP address spoofing § Problems with legi+mate clients like cloud servers § Google Premier used a public client_id and requires signed URLs – (Strips domain leaving only path and query parameters)
- 22. © 2014 CA. ALL RIGHTS RESERVED. Bo^om Line: The API Key Was Never Meant To Be Authorita+ve § Strange hybrid of HTTP’s USER-‐AGENT and session con+nuity § OK only for general tracking § Anything that ma^ers should use real security tokens – Anywhere where iden+ty is important: § APIs that provide access to sensi+ve data § APIs that change things that ma^er § APIs that charge for use § etc.
- 23. © 2014 CA. ALL RIGHTS RESERVED. Move to OAuth For People
- 24. © 2014 CA. ALL RIGHTS RESERVED. Mi+ga+on § 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-‐authorita+ve § Consider behavioral iden+fica+on of apps – Apps are rigid in their API flow Important!
- 25. © 2014 CA. ALL RIGHTS RESERVED. Problem Area #3: Cryptography and PKI § Cryptography is reasonably mature on the web – Surprisingly limited use pa^erns – SSL/TLS – Very li^le tough PKI (like client-‐side) § So what’s wrong with APIs?
- 26. © 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 – Revoca+on – Audit
- 27. © 2014 CA. ALL RIGHTS RESERVED. 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 – Indian NIC issue July 2014 § Subordinate CA issued fraudulent Google and Yahoo certs
- 28. © 2014 CA. ALL RIGHTS RESERVED. The Issues (cont.) § Cipher suite restric+ons – Avoiding downgrades § Client-‐side cer+ficate authen+ca+on is hard § The alterna+ves for parameter confiden+ality and/or integrity are hard: – XML encryp+on is s+ll there § Not for the faint of heart – OAuth 1.0 gave you parameter signing § Only op+onal in 2.0 – JWT signing and encryp+on emerging
- 29. © 2014 CA. ALL RIGHTS RESERVED. SSL Everywhere (it’s cheap)
- 30. © 2014 CA. ALL RIGHTS RESERVED. Mi+ga+ons § SSL everywhere § Use real PKI – I know it’s painful § Use HSMs to protect keys that really ma^er § Otherwise use real key material protec+on schemes – PKCS #12, etc – Libraries abound § You must do CRLs and OCSP for APIs
- 31. © 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…
- 32. © 2014 CA. ALL RIGHTS RESERVED. How Do I Apply This Today? § Use SSL for all API transac+ons – Hides many sins § Confiden+ality, integrity, replay, binding token+message, server authen+ca+on, etc. § Use real PKI – Yes, it’s hard – But you can’t skimp here § Use OAuth for distributed authen+ca+on § Validate all data going in and out of an API § Use real frameworks, don’t reinvent
- 33. SVP and Dis+nguished Engineer Sco^[email protected] @KSco^Morrison h^p://KSco^Morrison.com linkedin.com/KSco^Morrison ca.com K. Sco7 Morrison