Putting Web Security Issues to REST

Abstract: A common security mantra is "don't roll your own" - but when developing modern web APIs, this may seem easier said than done. Unlike older, over-specified API protocols, the general concepts which underpin REST APIs do not offer much guidance on security best-practices. Worse still, some techniques that have gained widespread use have been shown to be fundamentally flawed. This session will cover some common classes of mistakes in developing and using secure web APIs, and show how reinventing the wheel can sometimes be dangerous. Along the way, we'll cover problems with authentication and authorization, information leakage, and (im)proper uses of transport-layer security, among others.

Bio: Adam Goodman is a co-founder and Principal Security Engineer at Duo Security, where he and his cohorts work to radically improve the ease-of-use in strong authentication systems. He was previously a founding engineer at Zattoo, Europe's largest live-streaming Internet TV operator, where he led the development of the secure P2P distribution and digital rights management protocols that carried the first live broadcasts of Europe's second-largest pay TV operator over the Internet. Adam also enjoys puns way too much for his own good...

Transcript

1. Adam Goodman
   PUTTING WEB API
   SECURITY ISSUES TO REST
   

   View Slide

2. REST?
   h p://www.etsy.com/listing/85275007/soap-sleeping-ki en-soap-pink-relaxing
   

   View Slide

3. REINVENTING THE WHEEL
   h p://www.flickr.com/photos/vrogy/514733529/
   

   View Slide

4. INFORMATION SECURITY
   ˒  Confidentiality
   ˒  Authenticity
   ˒  Integrity
   ˒  Availability
   ˒  (...)
   

   View Slide

5. CONFIDENTIALITY
   

   View Slide

6. AUTHENTICITY
   h p://www.pxleyes.com/photoshop-contest/6964/zip-it.html
   

   View Slide

7. INTEGRITY
   

   View Slide

8. AVAILABILITY
   h p://www.flickr.com/photos/mr_t_in_dc/4264146249/
   

   View Slide

9. SSL/TLS
   ˒  Designed to guarantee all of:
   ˒  Confidentiality
   ˒  Integrity
   ˒  Authenticity
   

   View Slide

10. SSL CERTIFICATE
    

    View Slide

11. ASIDE: CHAIN OF TRUST
    Root Authority
    Intermediate
    Authority
    Intermediate
    Authority
    example.com
    SSL/TLS Client
    

    View Slide

12. SSL CERTIFICATE VALIDATION
    ˒  Is the name on the certificate correct?
    ˒  HTTPS: does it match the server`s hostname
    ˒  Was the certificate issued by a trusted authority?
    ˒  Is the certificate`s signature correct?
    ˒  Is the certificate unexpired?
    

    View Slide

13. BUT...
    

    View Slide

14. PYTHON FAIL!
    In Python versions before 3.2, there is no support in
    the Standard Library (urllib / h plib) for checking
    SSL certificates while performing HTTPS requests
    

    View Slide

15. PYTHON FAIL!
    ˒  python-cloudfiles (Rackspace CloudFiles client
    SDK)
    ˒  recurly-client-python
    ˒  boto* (widely-used python AWS client library)
    ˒  many others...
    * boto recently implemented support for checking CA certificates, but it remains
    disabled by default.
    

    View Slide

16. OTHER PYTHON HTTP LIBRARIES
    PyCURL YES NO
    h plib2 YES YES
    urllib3 YES NO
    Twisted NO* NO
    * Twisted can check CA signatures, but can’t verify that the certificate matches the
    hostname
    

    View Slide

17. OTHER ENVIRONMENTS
    Ruby (NET:HTTP) YES NO*
    Java (java.net.URL) YES YES
    .NET
    (System.net.WebClient)
    YES YES
    Cocoa
    (NSURLConnection)
    YES YES
    * Ruby’s NET:HTTP library will log a warning to the console by default
    

    View Slide

18. SSL CERTIFICATE VALIDATION
    ˒  Is the name on the certificate correct?
    ˒  HTTPS: does it match the server`s hostname
    ˒  Was the certificate issued by a trusted authority?
    ˒  Is the certificate`s signature correct?
    ˒  Is the certificate unexpired?
    ˒  Has the certificate been revoked?
    

    View Slide

19. REVOCATION...
    ˒  Certificate Revocation Lists (CRLs)
    ˒  Certificate Authority publishes a (signed) list of
    certificate IDs that should no longer be
    considered valid
    ˒  Online Certificate Status Protocol (OCSP)
    ˒  Given a certificate ID, returns a (signed)
    response indicating whether that certificate is
    still valid
    

    View Slide

20. REVOCATION...
    ˒  ... doesn`t really work...
    ˒  Applications and libraries frequently don`t
    check CRLs or OCSP
    ˒  Even those that do will rarely complain if they
    can`t reach the server hosting the CRL or OCSP
    service
    

    View Slide

21. Y U NO VALIDATE?
    

    View Slide

22. CERTIFICATE AUTHORITY FAIL
    h p://www.infoworld.com/d/security/hackers-target-google-skype-rogue-ssl-certificates-603
    

    View Slide

23. CERTIFICATE AUTHORITY FAIL
    h p://www.scmagazine.com/diginotar-breach-fallout-widens-as-more-details-emerge/article/211349/
    

    View Slide

24. TRUSTING CERTIFICATE AUTHORITIES
    ˒  Over 150 Root Authorities are trusted by most
    OS`s and browsers
    ˒  Even scarier - intermediate authorities beneath
    them also can issue certificates for anyone
    ˒  Cross-signing: sometimes, lesser-known root
    authorities act as intermediate authorities,
    signed off by other - more trusted - root
    authorities (e.g. Equifax)
    

    View Slide

25. TRUSTING CERTIFICATE AUTHORITIES
    Make sure you validate SSL certificates. Limit the
    authorities that you trust, if possible (but be aware
    that cross-signed roots can thwart this)
    

    View Slide

26. SSL/TLS
    ˒  Is a pre y good, secure protocol...
    ˒  ... if you use it correctly ...
    ˒  ... if you`re pedantic about checking for revoked
    certificates ...
    ˒  ... except if you trust the wrong CA`s ...
    ˒  ... except for the occasional design (or
    implementation) flaw ...
    

    View Slide

27. LAYERED APPROACH TO SECURITY
    Where possible, build systems with multiple lines of
    defense - so even if one falls, all is not lost…
    

    View Slide

28. LAYERED APPROACH TO SECURITY
    ˒  Example: Firefox Updates
    ˒  Firefox relied solely on SSL to authenticate
    browser updates
    ˒  In 2009, Moxie Marlinspike found a way to forge
    certificates, including for Mozilla`s update
    servers - could have tricked Firefox into auto-
    downloading malicious code.
    h p://safecomputing.umich.edu/events/sumit09/docs/Moxi%20more2.pdf
    

    View Slide

29. LAYERED APPROACH TO SECURITY
    ˒  Example: Firefox Updates
    ˒  Now, Firefox update payloads are signed, too.
    

    View Slide

30. AUTHENTICATION
    (from h p://www.youtube.com/watch?v=N7L5RjiCM-c)
    

    View Slide

31. HTTP BASIC
    GET /protected_resource HTTP/1.1
    Host: example.com
    Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    

    View Slide

32. HTTP BASIC
    $ python
    Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
    ...
    >>> auth = "QWxhZGRpbjpvcGVuIHNlc2FtZQ=="
    >>> auth.decode('base64')
    'Aladdin:open sesame'
    ... This might as well be plaintext!
    

    View Slide

33. FLICKR API SIGNATURE (2009)
    ˒  Sort parameters alphabetically. Call the name of
    the first parameter key1, its value value1, and so on.
    ˒  Construct a string:
    tosign = SECRET + key1 + value1 + key2 + value2 + ...
    ˒  Compute:
    sig = md5(tosign)
    ˒  Append a parameter “api_sig” to the parameter
    list, with sig as its value.
    

    View Slide

34. FLICKR API SIGNATURE (2009)
    ˒  Designed to be secure even without SSL
    ˒  Only signing the request parameters?
    ˒  Request is always a GET
    ˒  Request is always directed to one URL endpoint
    (API method specified as a parameter)
    

    View Slide

35. FLICKR API SIGNATURE (2009)
    For an unsigned query string:
    “method=flickr.auth.getFrob&api_key=12345”
    We have:
    tosign = \
    “SECRETapi_key12345methodflickr.auth.getFrob”
    sig = md5(tosign) # “b9195b9911e6a5c92efc50a31bû8bb7”
    Yielding the signed query string:
    “method=flickr.auth.getFrob&api_key=12345&api_sig=
    b9195b9911e6a5c92efc50a31bû8bb7”
    

    View Slide

36. MD5 LENGTH EXTENSION ATTACK
    ˒  For a string m, if you know md5(m) and len(m),
    then you can compute md5(m + pad(m) + m’) for
    any new message m’
    ˒  Flickr`s secrets were a fixed length; len(m) is trivial
    to calculate if you intercept an API request
    h p://netifera.com/research/flickr_api_signature_forgery.pdf
    

    View Slide

37. MD5 LENGTH EXTENSION ATTACK
    ˒  If an a acker intercepts a signed request:
    api_key=12345&method=flickr.auth.getFrob&api_si
    g= b9195b9911e6a5c92efc50a31bû8bb7
    ˒  Then, he could easily compute a valid signature for
    a request like:
    api_key=12345&method=flickr.auth.getFrob[PADDI
    NG]&sinister_param=foobar
    ˒  But this probably wouldn`t do much...?
    

    View Slide

38. NO DELIMITERS!
    ˒  Consider:
    ˒  lfoo=bar&greeting=hiz
    ˒  lf=oobargreetinghiz
    ˒  For both of these:
    ˒  tosign = “SECRETfoobargreetinghi”
    

    View Slide

39. FLICKR API FAIL
    ˒  If an a acker intercepts a signed request:
    api_key=12345&method=flickr.auth.getFrob&api_si
    g=b9195b9911e6a5c92efc50a31bû8bb7
    ˒  Then, he could sign another request:
    a=pi_key12345methodflickr.auth.getFrob[PADDIN
    G]&api_key=12345&method=do.something.EVIL
    ˒  If Flickr ignores the invalid ba` parameter, all is
    lost!
    

    View Slide

40. NOT JUST FLICKR
    ˒  Scribd
    ˒  Vimeo
    ˒  Remember The Milk (not exploitable?)
    ˒  Amazon Web Services API v1 (missing delimiters,
    but no length extension)
    ˒  many others...
    

    View Slide

41. LESSONS FROM FLICKR
    ˒  HMAC
    ˒  First published in 1996
    ˒  Designed specifically to avoid problems like
    length extension!
    ˒  Make sure the signature includes any necessary
    information about the structure of the message
    

    View Slide

42. LESSONS FROM FLICKR
    Don`t design your own signature scheme (but also be
    careful when copying someone else’s!)
    

    View Slide

43. GOOD: AWS SIGNATURE V2
    Create a canonical representation of your request:
    GET
    /protected/resource
    example.com
    param1=value1&param2=value2&param3=value3
    Then compute:
    sig = HMAC-SHA1(canonical_string, SECRET)
    h p://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-query-api.html
    

    View Slide

44. REPLAY ATTACKS
    ˒  If an a acker captures an API request, he can still
    re-send it without modification
    ˒  (Imperfect) Solutions:
    ˒  Timestamp (e.g. AWS ‘Expires’ parameter)
    ˒  Nonce
    

    View Slide

45. WORSE: AWS SIGNATURE V3 (?)
    ˒  HMAC of current time
    ˒  As useful to an a acker as a time-limited
    password
    ˒  “To avoid replays of your requests, AWS requires
    the time stamp in the request to be within 5
    minutes of the AWS system time.”
    

    View Slide

46. OAUTH
    ˒  Heavier-weight, but worth a look
    ˒  Defines external authentication/authorization
    architecture for your API
    ˒  Complicated to implement (but there are
    libraries)
    

    View Slide

47. AUTHORIZATION
    

    View Slide

48. CITIGROUP FAIL
    h p://www.wired.com/threatlevel/2011/06/citibank-hacked/
    

    View Slide

49. CITIGROUP FAIL
    h p://www.theinquirer.net/inquirer/news/2079431/citibank-hacked-altering-urls
    

    View Slide

50. ENFORCING AUTHORIZATION
    ˒  Have a clear understanding of what information is
    secret and what is not
    ˒  Account IDs should not be considered secret...
    ˒  Make sure that users cannot access resources that
    are not theirs to access (no ma er how hidden
    they may otherwise be)
    

    View Slide

51. INFORMATION LEAKAGE
    (The SQRT function)
    

    View Slide

52. EXAMPLE: RESPONSE CODES
    Client:
    GET /account/alice HTTP/1.1
    Host: example.com
    Server:
    404 NOT FOUND
    What’s the difference?
    Client:
    GET /account/bob HTTP/1.1
    Host: example.com
    Server:
    401 UNAUTHORIZED
    

    View Slide

53. EXAMPLE: RESPONSE CODES
    What’s the difference?
    ... Now we know an account named ‘bob’ exists!
    Client:
    GET /account/alice HTTP/1.1
    Host: example.com
    Server:
    404 NOT FOUND
    Client:
    GET /account/bob HTTP/1.1
    Host: example.com
    Server:
    401 UNAUTHORIZED
    

    View Slide

54. EXAMPLE: RESPONSE CODES
    (unless the server is just messing with us – but it
    probably isn’t…)
    Client:
    GET /account/alice HTTP/1.1
    Host: example.com
    Server:
    404 NOT FOUND
    Client:
    GET /account/carol HTTP/1.1
    Host: example.com
    Server:
    418 I’M A TEAPOT
    

    View Slide

55. INFORMATION LEAKAGE
    ˒  Don`t reveal anything unnecessarily
    ˒  Anything you say can and will be used against
    you :)
    ˒  (Need to balance this with usability)
    

    View Slide

56. BONUS: HASH TABLE DENIAL-OF-SERVICE
    h p://www.flickr.com/photos/joyosity/3357796927/
    

    View Slide

57. HASH TABLE
    POST /api/method HTTP/1.1
    Host: example.com
    Content-Type: application/x-www-form-urlencoded
    Content-Length: ...
    ...
    param1=value1&param2=value2&param3=value3&...
    

    View Slide

58. HASH TABLE
    $ python
    ...
    >>> phones = {
    ... 'Bob': '555-1234',
    ... 'Jane': '555-9876',
    ... 'Mike': '555-2468'
    ... }
    >>> phones['Bob']
    '555-1234'
    

    View Slide

59. HASH TABLE
    Bob
    Jane
    ...
    00
    01
    02
    14
    15
    555-1234
    555-9876
    Bob
    Jane
    Hash Function
    

    View Slide

60. COLLISIONS
    Bob
    Jane
    ...
    00
    01
    02
    14
    15
    555-1234
    555-9876
    Bob
    Jane
    Hash Function
    Mike
    Mike 555-2468
    

    View Slide

61. WORST CASE
    Your hash table just became a linked list...
    Bob
    ...
    00
    01
    02
    555-1234
    Bob
    Mike
    Hash Function
    Charlie
    Mike 555-2468
    Charlie 555-3456
    James 555-4567
    James
    

    View Slide

62. WORST CASE
    PHP 5 500 KB 60 seconds*
    ASP.NET 330 KB 90 seconds*
    Tomcat (Java)† 2 MB* 44 minutes
    Plone (Python) 1 MB* 7 minutes
    Ruby 1.8† 2 MB* 6 hours
    h p://www.nruns.com/_downloads/advisory28122011.pdf
    * default limit enforced by web server
    † fixed in recent updates
    

    View Slide

63. CLEVER NEW ATTACK?
    ˒  lDenial of service via algorithmic complexity
    a acksz
    ˒  Presented by Sco Crosby and Dan Wallach at
    Usenix Security in 2003!
    h p://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
    

    View Slide

64. AVAILABILITY
    ˒  Place limits on the resources that a single request
    can consume
    ˒  CPU time
    ˒  Wall time
    ˒  Request size
    ˒  Consider making your API partition-tolerant
    ˒  customer1.yoursite.com,
    customer2.yoursite.com, ...
    

    View Slide

65. QUESTIONS?
    ˒  Email: akgood@duosecurity.com
    ˒  Twi er: @akgood
    

    View Slide