CIS14: Best Practices You Must Apply to Secure Your APIs


Published on

Scott Morrison, CA Technologies

Good practices to put in place and the common security antipatterns you must avoid to ensure your company’s APIs are reliable, safe and secure; includes top ways hackers exploit APIs in the wild, common identity pitfalls and how to avoid them, why OAuth scopes are essential to master, and how to keep web developers from bringing bad habits with them.

Published in: Technology
1 Comment
  • nice post!
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CIS14: Best Practices You Must Apply to Secure Your APIs

  1. 1. Best  Prac*ces  You  Must  Apply  to   Secure  Your  APIs     K.  Sco7  Morrison   SVP  and  Dis+nguished  Engineer      
  2. 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. 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. 4. ©  2014  CA.  ALL  RIGHTS  RESERVED.   For  Example:   GET  
  5. 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"                    }            ]    }  
  6. 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. 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. 8. ©  2014  CA.  ALL  RIGHTS  RESERVED.   Good  Web  Apps  Constrain     HTTP  Server   App  Server   Database   Web  Client   Objects   Pages   Constraint   Space   Records  
  9. 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. 10. ©  2014  CA.  ALL  RIGHTS  RESERVED.   APIs  Also  Increase   A7ack  Surface  
  11. 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. 12. ©  2014  CA.  ALL  RIGHTS  RESERVED.   SQL  Injec+on  is  Another   Source:  h^ps://     Exploits of a Mom
  13. 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. 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. 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://  
  16. 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. 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://  )  
  18. 18. ©  2014  CA.  ALL  RIGHTS  RESERVED.   For  Example:   GET   ?APIKey=15458617-­‐7813-­‐4a37-­‐94ac-­‐a8e6da6f6405     Seriously?  WTF.  
  19. 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. 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. 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. 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. 23. ©  2014  CA.  ALL  RIGHTS  RESERVED.   Move  to  OAuth  For  People  
  24. 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. 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. 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. 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. 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. 29. ©  2014  CA.  ALL  RIGHTS  RESERVED.   SSL  Everywhere   (it’s  cheap)  
  30. 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. 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. 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. 33. SVP  and  Dis+nguished  Engineer   Sco^   @KSco^Morrison   h^p://KSco^^Morrison   K.  Sco7  Morrison