Pentesting RESTful webservices

  • 8,933 views
Uploaded on

Pentesting RESTful webservices talks about problems penetration testers face while testing RESTful Webservices and REST based web applications. The presentation also talks about tools and techniques …

Pentesting RESTful webservices talks about problems penetration testers face while testing RESTful Webservices and REST based web applications. The presentation also talks about tools and techniques to do pentesting of RESTful webservices.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
8,933
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
177
Comments
4
Likes
17

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ` ces vi sting er ente P bS e lW Tfu ES R MOH IMRAN MED A. AM
  • 2. Hello MI MOHAMMED A. IMRAN Application Security Engineer, CA Inc Null Hyderabad Lead OWASP Hyderabad Board Member @MohammedAImran Created and Designed using
  • 3. LET’S TALK ABOUT ... WHAT IS RESTful WEB SERVICES? PROBLEMS WITH REST WS TESTING TOOLS & TECHNIQUES METHODOLOGY TO TEST RESTful WS
  • 4. DID YOU ? KNOW
  • 5. THE UGLY TRUTH SOAP Webservices VS RESTful Webservices Google Trends
  • 6. They also rest on REST APIs
  • 7. Why REST WebServices ?
  • 8. Easy & Simple GET /users/313/ VS <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.mysite.com/users">   <m:GetUserDetails>     <m:UserID>313</m:UserID>   </m:GetUserDetails> </soap:Body> </soap:Envelope>
  • 9. Light weight { "login": "MohammedAImran", "type": "User", "site_admin": false, "name": "Mohammed A. Imran", "company": "CA Inc", "email": "morpheus@null.co.in" } <soap:Body xmlns:m="http://www.mysite.com/users">   <m:GetUserDetailsResponse>     <m:UserName>MohammedAImran</m:UserName> <m:Type>user</m:Type> VS <m:SiteAdmin>false</m:SiteAdmin> <m:UserName>Mohammed A.Imran</m:UserName> <m:Company>CA Inc</m:Company> <m:Email> morpheus@null.co.in </m:Email>   </m:GetUserDetailsResponse> </soap:Body> Note: REST can also use XML as media type
  • 10. Many more reasons to use ... ● Easy to understand & document ● Easy on limited bandwidth ● READS can be cached and hence reduces the bandwidth ● Better browser support since data format mostly is json ● Can be used by mobile devices ● Loosely coupled
  • 11. But what is REST ?
  • 12. “ Representational state transfer (REST) is an architectural style consisting of a coordinated set of constraints applied to components, connectors, and data elements, within a distributed hypermedia system.
  • 13. What ? Let me explain ... REST is an architectural style with some imposed constraints in how data is accessed and represented while developing web services or applications. It uses HTTP 1.1 as inspiration.
  • 14. In simple terms REST = RFC 2616almost Well,
  • 15. In simple terms ... REST = HTTP Protocol with constraints
  • 16. Architecture constraints ● Uniform interface ● Client-server ● Stateless ● Cache-able ● Layered system ● Code on demand(optional)
  • 17. REST Style consists of ... Resources VERBS Media Types Status Codes
  • 18. REST Style consists of ... Resource URLs VERBS Media Types Status Codes
  • 19. Collection RESOURCES INSTANCE RESOURCES RESOURCES Site.com/users/1 Site.com/users NOUN
  • 20. REST Style consists of ... Resources VERBS Media Types Status Codes
  • 21. DELETE VERBS POST PUT READ
  • 22. POST = CREATE some resource Create a new * * POST can be used for both create and update
  • 23. POST http://mysite.com/users/ { } "login": "MohammedAImran", "id": "313", "name": "Mohammed A. Imran", "company": "CA Inc", "email": "MohammedAbdullahImran@gmail.com"
  • 24. GET = READsome resource Fetch
  • 25. GET site.com/users/ { users:[ { "login": "MohammedAImran", "id": "313", "name": "Mohammed A. Imran", "company": "CA Inc", "email": "MohammedAbdullahImran@gmail.com"}, { "login": "Raghunath", "id": "311", "name": " G Raghunath", "company": "X Inc", "email": "raghu@null.co.in"}] }
  • 26. GET site.com/users/313 { "login": "MohammedAImran", "id": "313", "name": "Mohammed A. Imran", "company": "CA Inc", "email": "MohammedAbdullahImran@gmail.com" }
  • 27. PUT =UPDATE/MODIFY Update some resource * * PUT can be used for both create and update
  • 28. DELETE = DELETE Delete a resource
  • 29. REST Style consists of ... Resources VERBS Media Types Status Codes
  • 30. HATEOAS Hypermedia As The Engine Of Application State
  • 31. = + Specifications Parsing Rules Media Types
  • 32. Media Type Examples Application/json Application/xml Application/imrans+json;v1
  • 33. REST Style consists of ... Resources VERBS Media Types Status Codes
  • 34. Status Codes 200 OK 201 Created 204 No Content 304 Not Modified 500 Internal Server Error 501 Not Implemented 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 405 Method Not Allowed 409 Conflict
  • 35. RESTful WS testing problems
  • 36. Difficulty in doing REST PT ● Many JSON variables to fuzz and difficult to find which ones are optional and to be fuzzed ● Custom authentication ● Statelessness ● Non common HTTP status codes which tools are used to
  • 37. Difficulty in doing REST PT ... ● ● ● Not so good automated tool support Every API is different from other and hence need custom tweaking for tools Heavy reliance on Ajax frameworks for creating PUT and DELETE requests as most browsers don’t support them
  • 38. REST WS testing Methodology
  • 39. Authentication
  • 40. Bad practices http://site.com/token/a3b3c2be5f53c8/ https://site.com/token/a3b3c2be5f53c8/
  • 41. Authentication ... ● REST APIs rely heavily on SSL ● Often basic authentication is coupled with SSL ( Bruteforce ? ) ● Often custom token authentication schemes are built and used ( a sure recipe for disaster) ● Never pass username/password, tokens, keys in URL (use POST instead ) ● Implementing authentication tokens in Headers takes away headache of having a CSRF token
  • 42. Session Management ● Check all session based attacks on tokens as well ● Session timeout ● Session brute force ● ● Generally tokens are stored in local storage of browsers, make sure you delete the token after log-out and upon browser window close Invalidate the token at server side upon on logout
  • 43. Authorization ● Privilege escalation (Horizontal and Vertical) ● Make sure there is a tight access control on DELETE, PUT methods ● Use role based authentication ● ● Since usually the consumers of the REST APIs are machines, there are no checks if service is heavily used, could lead to DoS or BruteForce. Protect administrative functionality
  • 44. CVE-2010-0738
  • 45. JBOSS JMX Console Vulnerability
  • 46. NOTE All attacks which are possible on any web application are possible with REST APIs as well.
  • 47. Input Validation ● SQL Injection ● XSS ● Command Injection ● XPATH Injection However XSS becomes difficult to fuzz because of JSON and you might want to scan with sql injection and xss profiles separately
  • 48. Output encoding ● If you application has a web interface then might want to use the following headers: X-Content-Type-Options: nosniff – X-Frame-Options: DENY/SAMEORIGIN/ALLOW-FROM JSON Encoding – ●
  • 49. Cryptography ● ● Use TLS with good key size (384 bits preferably) Use client side certificates possible however not usually seen for APIs ● Use strong hashing algorithms(scrypt/bcrypt/SHA512) ● Use strong encryption mechanisms (AES)
  • 50. Few notes ... ● ● ● ● Use proxy to determine the attack surface and to understand the application Identify URLs, Resources, status codes and data needed Every part of the http protocol is potential for fuzzing in RESTful APIs (dont forget headers) WAF evasion is possible since json is not well understood by WAFs
  • 51. Tools & Techniques
  • 52. Command-line-Fu
  • 53. cURL Primer cURL -b or - -cookie ”COOKIE HERE” -h or - -header “Authorization: Custom SW1yYW5XYXNIZXJlCg==” -X or - -request PUT/POST/DELETE -i or - -include //include response headers -d or - -data “username=imran&password=Imran” or - -data @filecontaining-data -x or - - proxy 127.0.0.1:8080 -A or - -user-agent ”Firefox 27.0”
  • 54. cURL Primer ... ● ● ● cURL is great for automation if you know how service works. cURL libraries are available for majority of the languages like php, python and many more... You can perform complex operations and script them pretty fast.
  • 55. cURL Examples #!/bin/bash users="Imran Jaya Raghu Vinayak" for dirName in $users do curl -i -H “Authorization: Custom SW1yYW5XYXNIZXJlCg==” "http://www.mysite.com/users/$dirName" --proxy 127.0.0.1:8080 done
  • 56. Graphical Tools
  • 57. Firefox Add-on
  • 58. Firefox Add-on ... ● ● If you need graphical interface, browser add-ons provide GUI, however not as powerful as the cURL command. Specialized developer tools ( SOAP UI ) can also be used for testing.
  • 59. Automated Tools
  • 60. AppScan Scan http://blog.watchfire.com/wfblog/2012/01/testing-restful-services-with-appscan-standard.html
  • 61. AppScan Scan...
  • 62. Thank you ! Want to discuss more ? Catch me on www.twitter.com/MohammedAImran www.linkedin.com/in/MohammedAImran
  • 63. You might like these as well!
  • 64. Credits * All icons are taken from The Noun project, credit goes to respective artists * OWASP Cheat sheet series
  • 65. References http://www.slideshare.net/SOURCEConference/security-testing-for-rest-applications-ofer-shezaf-source-barcelona-nov-2011 https://www.owasp.org/index.php/REST_Security_Cheat_Sheet http://securityreliks.wordpress.com/2010/07/28/testing-restful-services-with-appscan/ http://www-01.ibm.com/support/docview.wss?uid=swg21412832 http://blog.watchfire.com/wfblog/2012/01/testing-restful-services-with-appscan-standard.html