SlideShare a Scribd company logo

Web API Security

•
•
S
Stefaan

This presentation gives an impression of the threats you are facing when designing or developing a web API.

Related slideshows

Pentesting Rest API's by :- Gaurang Bhatnagar
Pentesting Rest API's by :- Gaurang BhatnagarPentesting Rest API's by :- Gaurang Bhatnagar
Pentesting Rest API's by :- Gaurang Bhatnagar
 
Api security
Api security Api security
Api security
 
OWASP Top 10 Proactive Controls
OWASP Top 10 Proactive ControlsOWASP Top 10 Proactive Controls
OWASP Top 10 Proactive Controls
 
1 of 38
API Security learning from a Pentesters POV API Strategy Workshop March 2015 Dr. Ir. Stefaan Seys, ZIONSECURITY
Who am I 2  Stefaan Seys  Security Expert at ZIONSECURITY  Postdoc researcher at KU Leuven / COSIC COSIC
Outline 3  (no exponential graphs on nr of attacks, etc.)  High level security architecture and objectives  API security threats and prevention  Authentication and SSL/TLS  History revisited  Messages to take home
High level API security architecture
End-to-End Security Components 5 API ServiceConsumer Threat Protection Authentication / Authorization Logging / Auditing Security Analytics Confidentiality Development Access Identity Service Authentication / Authorization Confidentiality Identity Service API Consumption Security API Exposure Security Threat Protection
Who is the Consumer? 6 API Service Browser or Browser plug-in Mobile App Back-end Service Not possible to hide long-term secrets. Very tempting to hide long-term secrets. OK to use long-term secrets.
API Security Threats and Prevention
Discovery 8 Public APIs are designed to be used by ‘external’ parties  Documentation  API descriptors in standard formats  URI-style: Swagger, RAML, API-Blueprint, I/O Docs, etc.  SOAP: WSDL/XML-Schema  Hypermedia: JSON-LD, Siren, Hydra, etc.  This obviously helps in the discovery phase 
Swagger example 9 "paths": { "/pet/{petId}": { "delete": { "tags": ["pet"], "summary": "Deletes a pet", "description": "", "operationId": "deletePet", "produces": ["application/json", "application/xml"], "security": [{ "petstore_auth": ["write:pets", "read:pets"] }] "parameters": [{ "name": "petId", "in": "path", "description": "Pet id to delete", "required": true, "type": "integer", "format": "int64" }], . . . Attack point HTTP method, how does it handle unspecified methods? OAUTH 2: which implementation?, known vulnerabilities? How does it validate tokens? Scopes? Is access validated? Link between user and petId? Are IDs random? Injection? XSS? What if we do not set the “petId”? What if we do not give an int? Or > int64 max size?
“Classic Discovery” in case the API is secret 10 What about just keeping your API secret?  Local Proxy or network sniffer  Guess / brute-force APIs  http://api.*.com/api/v?/*.json
Public API with a secret API key… 11 March 2014 Issue was already reported to them in 2010...
Story 12  Install the official Android App  Extract the APK file and install on an emulator  Use TCPDUMP to listen to traffic from App  Start App, enter garbage at login page  GET /handler.php?CritickerKey=xxxxx&Function=UserSignin&UserName=asdf asdf&Password=6d2dedb5b9e02d466a8d98b4c4398b1d  The Criticker API has a call to get the list of users!  GET handler.php?CritickerKey=xxxxx&Function=AccountUsers  And a call to request the current password! In plaintext!!  GET handler.php?CritickerKey=xxxxx&Function=LookupPassword&UserId=xxx xx
What did they do wrong? 13  They created an API with “useless”, dangerous and documented features  Call to get list of all users?  Call to get password of a any user?  Passwords are stored in plain text on the server  They use plain HTTP (no SSL) �� The “key” is sent over the network with every call
Secret API with docs in error message 14  Basic authentication (over SSL, no cert pinning)  With static fixed username/password for all users (embedded in App)  Only ‘authentication’ is the userID  This userID is sequential (not random)  Returns a help file if you send a wrong API request
Assume your API is public…
Fuzzing and invalid input 16 http://api.openweathermap.org/data/2.5/weather?id=2172797  Attack vector:  Replace the id parameter with “randomly” generated value  Purpose:  Get information through error message  Prevention  Ensure generic, consistent and correct error messages that do not reveal any additional information
Malicious Input 17  Attack vector  Craft malicious input that targets specific message parser, implementation weakness, etc.  Vulnerable parser will recursively replace &lol9;  Resulting in a billion ‘lol’s; taking up 3GByte of RAM <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>
Malicious Input 18  Purpose  Attempt to put server in insecure state (if lucky)  Crash server  Prevention  Only use proven parsers  Patch your system  Input validation and sanitation
(SQL) Injection 19 http://api.openweathermap.org/weather?id=2172797 “SELECT * FROM forecast WHERE locID='” + id +”‘”;  Attack Vector  /weather?id=5’%20or%20’1’=’1  SELECT * FROM forecast WHERE locID=‘5’ or ‘1’=‘1’ [xkcd]
(SQL) Injection 20  Purpose  If used for authentication: get access without credentials  Dump database  Clear database  Prevention  Never use String operations to create ‘semi-structured” data objects such as SQL queries, JSON, XML, Xpath, etc.  Use a parameterized API to construct the object instead  If not available: carefully ensure escaping all special characters depending on the syntax of the interpreter
Cross Site Scripting (XSS) 21 Persistent XSS API Server 1. Inject malicious script  Prevention  Use context-aware auto-escaping  When?
Cross Site Request Forgery (CSRF) 22 MyFace.com Authenticated Session Victim lured to visit attacker’s site <a href=“https://www.myface.com/ update.php?relationship=Single%2 0and%20Desperate>Free beer</a> POST
Cross Site Request Forgery (CSRF) 23  Purpose  Force end-user to execute a state-changing request (as attacker never sees response).  Change user’s email address, reset password, transfer funds, …  Prevention  Include a per request random authentication code that is verified on the server (once!)
CSRF does not apply to APIs… 24  Normally SOAP and REST API authentication is not done through a session (cookie)  Instead, every API call contains authentication information  In a URL parameter  In the HTTP header (Oauth)  Part of the XML body (SOAP)  If you stick to these principles and use proper authentication/authorization model, CSRF does not apply.
Authentication and SSL
Authentication 26  Basic/Digest authentication  Uses HTTP headers to identify users  WS-Security SAML and Username Tokens  SOAP/XML based authentication, passes credentials and assertions in SOAP message headers, optionally signed and encrypted  API Key based authentication  each request to an API contains a key uniquely identifying the client  OAuth 1.x/2  HTTP-based interactions and flows that authorize usage of HTTP resources (API, Web, etc). OAuth indirectly includes a step for authentication but makes no claims on how that authentication should be done.  JSON web tokens
Username / password ? 27 Apple Celebrity photo hack  Hidden API to find your phone  https://fmipmobile.icloud.com/fmipservice/device/ <apple_id>/initClient  Basic Authentication through SSL tunnel <apple_id> : <password>  So far so good…  Server does not limit the number of attempts…  Same password for all you i-things on Apple (iCloud)
SSL’s Role 28 SSL – The Good  Secures the actual client authentication; as majority of web authentication is based on passwords/tokens  Compatible with vast amount of clients and servers  ‘Easy’ to set up (hard to do right)  Removes crypto burden from application developers
SSL’s Role 29 SSL – The Bad  Compatibility -> Complexity -> Vulnerabilities  For APIs it is also mostly the only crypto layer  If broken -> huge impact  “But we are using SSL…”: it does not magically make your site secure…  If used with server side certs only, client side authentication is not in scope  Transport layer security -> does not prevent many application layer problems (injection, XSS, etc.)
How did we get here?
OWASP Top 10 – A History 31 2004 2007 2010 2013 A1 Unvalidated Input A1 Cross Site Scripting (XSS) A1 Injection A1 Injection A2 Broken Access Control A2 Injection Flaws A2 Cross Site Scripting (XSS) A2 Broken Authentication and Session Management A3 Broken Authentication and Session Management A3 Malicious File Execution A3 Broken Authentication and Session Management A3 Cross-Site Scripting (XSS) A4 Cross Site Scripting A4 Insecure Direct Object Reference A4 Insecure Direct Object References A4 Insecure Direct Object References A5 Buffer Overflow A5 Cross Site Request Forgery (CSRF) A5 Cross Site Request Forgery (CSRF) A5 Security Misconfiguration A6 Injection Flaws A6 Information Leakage and Improper Error Handling A6 Security Misconfiguration A6 Sensitive Data Exposure A7 Improper Error Handling A7 Broken Authentication and Session Management A7 Insecure Cryptographic Storage A7 Missing Function Level Access Control A8 Insecure Storage A8 Insecure Cryptographic Storage A8 Failure to Restrict URL Access A8 Cross-Site Request Forgery (CSRF) A9 Application Denial of Service A9 Insecure Communications A9 Insufficient Transport Layer Protection A9 Using Components with Known Vulnerabilities A10 Insecure Configuration Management A10 Failure to Restrict URL Access A10 Unvalidated Redirects and Forwards A10 Unvalidated Redirects and Forwards [Jim DelGrosso]
In Conclusion
Messages to take home 33  Security is very difficult to get right  Do not reinvent or worse, “improve” the wheel yourself  Web API’s suffer more or less from the same general ‘issues’ as web applications  However, API ‘structure’ allows for dedicated security enforcement point  Messaging (Request/Response)  Authentication  Authorization  Tailor (authentication mechanism) to your consumer  Take your SSL setup seriously
Questions 34 Thank you! ?
35
36
What’s Up with SSL? 37  BEAST (2011, CBC padding crypto attack, <TLS1.1)  RC4 (2013, 223 encryptions required, RC4)  BREACH (2013, clever crypto attack, universal)  Heartbleed (2014, openssl buffer overread, 1.0.1 to 1.0.1f)  POODLE (2014, ~BEAST, SSL3.0, TLS?)  FREAK (2015, RSA_EXPORT factoring, various)  Who says you can trust root certificates in your browser?  177 root certs in Firefox
Cross Site Scripting (XSS) 38 Reflective XSS API Server  Prevention  Use context-aware auto-escaping  When?

More Related Content

Web API Security

  • 1. API Security learning from a Pentesters POV API Strategy Workshop March 2015 Dr. Ir. Stefaan Seys, ZIONSECURITY
  • 2. Who am I 2  Stefaan Seys  Security Expert at ZIONSECURITY  Postdoc researcher at KU Leuven / COSIC COSIC
  • 3. Outline 3  (no exponential graphs on nr of attacks, etc.)  High level security architecture and objectives  API security threats and prevention  Authentication and SSL/TLS  History revisited  Messages to take home
  • 4. High level API security architecture
  • 5. End-to-End Security Components 5 API ServiceConsumer Threat Protection Authentication / Authorization Logging / Auditing Security Analytics Confidentiality Development Access Identity Service Authentication / Authorization Confidentiality Identity Service API Consumption Security API Exposure Security Threat Protection
  • 6. Who is the Consumer? 6 API Service Browser or Browser plug-in Mobile App Back-end Service Not possible to hide long-term secrets. Very tempting to hide long-term secrets. OK to use long-term secrets.
  • 7. API Security Threats and Prevention
  • 8. Discovery 8 Public APIs are designed to be used by ‘external’ parties  Documentation  API descriptors in standard formats  URI-style: Swagger, RAML, API-Blueprint, I/O Docs, etc.  SOAP: WSDL/XML-Schema  Hypermedia: JSON-LD, Siren, Hydra, etc.  This obviously helps in the discovery phase 
  • 9. Swagger example 9 "paths": { "/pet/{petId}": { "delete": { "tags": ["pet"], "summary": "Deletes a pet", "description": "", "operationId": "deletePet", "produces": ["application/json", "application/xml"], "security": [{ "petstore_auth": ["write:pets", "read:pets"] }] "parameters": [{ "name": "petId", "in": "path", "description": "Pet id to delete", "required": true, "type": "integer", "format": "int64" }], . . . Attack point HTTP method, how does it handle unspecified methods? OAUTH 2: which implementation?, known vulnerabilities? How does it validate tokens? Scopes? Is access validated? Link between user and petId? Are IDs random? Injection? XSS? What if we do not set the ��petId”? What if we do not give an int? Or > int64 max size?
  • 10. “Classic Discovery” in case the API is secret 10 What about just keeping your API secret?  Local Proxy or network sniffer  Guess / brute-force APIs  http://api.*.com/api/v?/*.json
  • 11. Public API with a secret API key… 11 March 2014 Issue was already reported to them in 2010...
  • 12. Story 12  Install the official Android App  Extract the APK file and install on an emulator  Use TCPDUMP to listen to traffic from App  Start App, enter garbage at login page  GET /handler.php?CritickerKey=xxxxx&Function=UserSignin&UserName=asdf asdf&Password=6d2dedb5b9e02d466a8d98b4c4398b1d  The Criticker API has a call to get the list of users!  GET handler.php?CritickerKey=xxxxx&Function=AccountUsers  And a call to request the current password! In plaintext!!  GET handler.php?CritickerKey=xxxxx&Function=LookupPassword&UserId=xxx xx
  • 13. What did they do wrong? 13  They created an API with “useless”, dangerous and documented features  Call to get list of all users?  Call to get password of a any user?  Passwords are stored in plain text on the server  They use plain HTTP (no SSL)  The “key” is sent over the network with every call
  • 14. Secret API with docs in error message 14  Basic authentication (over SSL, no cert pinning)  With static fixed username/password for all users (embedded in App)  Only ‘authentication’ is the userID  This userID is sequential (not random)  Returns a help file if you send a wrong API request
  • 15. Assume your API is public…
  • 16. Fuzzing and invalid input 16 http://api.openweathermap.org/data/2.5/weather?id=2172797  Attack vector:  Replace the id parameter with “randomly” generated value  Purpose:  Get information through error message  Prevention  Ensure generic, consistent and correct error messages that do not reveal any additional information
  • 17. Malicious Input 17  Attack vector  Craft malicious input that targets specific message parser, implementation weakness, etc.  Vulnerable parser will recursively replace &lol9;  Resulting in a billion ‘lol’s; taking up 3GByte of RAM <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>
  • 18. Malicious Input 18  Purpose  Attempt to put server in insecure state (if lucky)  Crash server  Prevention  Only use proven parsers  Patch your system  Input validation and sanitation
  • 19. (SQL) Injection 19 http://api.openweathermap.org/weather?id=2172797 “SELECT * FROM forecast WHERE locID='” + id +”‘”;  Attack Vector  /weather?id=5’%20or%20’1’=’1  SELECT * FROM forecast WHERE locID=‘5’ or ‘1’=‘1’ [xkcd]
  • 20. (SQL) Injection 20  Purpose  If used for authentication: get access without credentials  Dump database  Clear database  Prevention  Never use String operations to create ‘semi-structured” data objects such as SQL queries, JSON, XML, Xpath, etc.  Use a parameterized API to construct the object instead  If not available: carefully ensure escaping all special characters depending on the syntax of the interpreter
  • 21. Cross Site Scripting (XSS) 21 Persistent XSS API Server 1. Inject malicious script  Prevention  Use context-aware auto-escaping  When?
  • 22. Cross Site Request Forgery (CSRF) 22 MyFace.com Authenticated Session Victim lured to visit attacker’s site <a href=“https://www.myface.com/ update.php?relationship=Single%2 0and%20Desperate>Free beer</a> POST
  • 23. Cross Site Request Forgery (CSRF) 23  Purpose  Force end-user to execute a state-changing request (as attacker never sees response).  Change user’s email address, reset password, transfer funds, …  Prevention  Include a per request random authentication code that is verified on the server (once!)
  • 24. CSRF does not apply to APIs… 24  Normally SOAP and REST API authentication is not done through a session (cookie)  Instead, every API call contains authentication information  In a URL parameter  In the HTTP header (Oauth)  Part of the XML body (SOAP)  If you stick to these principles and use proper authentication/authorization model, CSRF does not apply.
  • 26. Authentication 26  Basic/Digest authentication  Uses HTTP headers to identify users  WS-Security SAML and Username Tokens  SOAP/XML based authentication, passes credentials and assertions in SOAP message headers, optionally signed and encrypted  API Key based authentication  each request to an API contains a key uniquely identifying the client  OAuth 1.x/2  HTTP-based interactions and flows that authorize usage of HTTP resources (API, Web, etc). OAuth indirectly includes a step for authentication but makes no claims on how that authentication should be done.  JSON web tokens
  • 27. Username / password ? 27 Apple Celebrity photo hack  Hidden API to find your phone  https://fmipmobile.icloud.com/fmipservice/device/ <apple_id>/initClient  Basic Authentication through SSL tunnel <apple_id> : <password>  So far so good…  Server does not limit the number of attempts…  Same password for all you i-things on Apple (iCloud)
  • 28. SSL’s Role 28 SSL – The Good  Secures the actual client authentication; as majority of web authentication is based on passwords/tokens  Compatible with vast amount of clients and servers  ‘Easy’ to set up (hard to do right)  Removes crypto burden from application developers
  • 29. SSL’s Role 29 SSL – The Bad  Compatibility -> Complexity -> Vulnerabilities  For APIs it is also mostly the only crypto layer  If broken -> huge impact  “But we are using SSL…”: it does not magically make your site secure…  If used with server side certs only, client side authentication is not in scope  Transport layer security -> does not prevent many application layer problems (injection, XSS, etc.)
  • 30. How did we get here?
  • 31. OWASP Top 10 – A History 31 2004 2007 2010 2013 A1 Unvalidated Input A1 Cross Site Scripting (XSS) A1 Injection A1 Injection A2 Broken Access Control A2 Injection Flaws A2 Cross Site Scripting (XSS) A2 Broken Authentication and Session Management A3 Broken Authentication and Session Management A3 Malicious File Execution A3 Broken Authentication and Session Management A3 Cross-Site Scripting (XSS) A4 Cross Site Scripting A4 Insecure Direct Object Reference A4 Insecure Direct Object References A4 Insecure Direct Object References A5 Buffer Overflow A5 Cross Site Request Forgery (CSRF) A5 Cross Site Request Forgery (CSRF) A5 Security Misconfiguration A6 Injection Flaws A6 Information Leakage and Improper Error Handling A6 Security Misconfiguration A6 Sensitive Data Exposure A7 Improper Error Handling A7 Broken Authentication and Session Management A7 Insecure Cryptographic Storage A7 Missing Function Level Access Control A8 Insecure Storage A8 Insecure Cryptographic Storage A8 Failure to Restrict URL Access A8 Cross-Site Request Forgery (CSRF) A9 Application Denial of Service A9 Insecure Communications A9 Insufficient Transport Layer Protection A9 Using Components with Known Vulnerabilities A10 Insecure Configuration Management A10 Failure to Restrict URL Access A10 Unvalidated Redirects and Forwards A10 Unvalidated Redirects and Forwards [Jim DelGrosso]
  • 33. Messages to take home 33  Security is very difficult to get right  Do not reinvent or worse, “improve” the wheel yourself  Web API’s suffer more or less from the same general ‘issues’ as web applications  However, API ‘structure’ allows for dedicated security enforcement point  Messaging (Request/Response)  Authentication  Authorization  Tailor (authentication mechanism) to your consumer  Take your SSL setup seriously
  • 35. 35
  • 36. 36
  • 37. What’s Up with SSL? 37  BEAST (2011, CBC padding crypto attack, <TLS1.1)  RC4 (2013, 223 encryptions required, RC4)  BREACH (2013, clever crypto attack, universal)  Heartbleed (2014, openssl buffer overread, 1.0.1 to 1.0.1f)  POODLE (2014, ~BEAST, SSL3.0, TLS?)  FREAK (2015, RSA_EXPORT factoring, various)  Who says you can trust root certificates in your browser?  177 root certs in Firefox
  • 38. Cross Site Scripting (XSS) 38 Reflective XSS API Server  Prevention  Use context-aware auto-escaping  When?