Downloaded 453 times
Uploaded bySource Conference
Securty Testing For RESTful Applications
This document discusses security testing for RESTful applications. It begins with an introduction to RESTful web services and how they differ from SOAP web services in using HTTP methods to indicate actions and embedding parameters in requests. It notes challenges in testing RESTful applications including that documentation may not reveal the full attack surface and requests can be dynamically generated. It recommends using documentation, proxies, and fuzzing to determine parameters and potential vulnerabilities. The document concludes by discussing how automated pen testing works by crawling to determine the attack surface through both links and emulated JavaScript to find dynamic requests.
Securty Testing For RESTful Applications
- 1. Security Testing ForRESTful Applications Ofer Shezaf, HP Enterprise Security Products ofr@hp.com ©2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice
- 2. About Myself Currently, chief architect for Risk and Vulnerability Management at HP. I create security Security research and Product Management at Breach Security, a Web Application Firewalls products vendor. Electric Cars security… Director, Web Application Security Consortium. I am an application Founded the OWASP Israeli chapter. security veteran ModSecurity Core Rule Set Project, WASC Web Hacking Incident Database. Read my blog at http://www.xiom.com I really try to learn what information Be ready to some philosophy of science and cognitive psychology security is I live in Kibbutz Yiftah, Israel
- 3. In this Presentation AboutRESTful Web Services RESTful WS in the Wild Security of RESTful WS Pen-testing RESTful WS Automated security testing of RESTful WS Research Test Remediate
- 4. About RESTful WebServices About RESTful Web Services RESTful WS in the Wild Security of RESTful WS Pen-testing RESTful WS Automated security testing of RESTful WS 4
- 5. Web Services • Employing web technology (i.e. HTTP) for machine to machine communication. • Used for: – Inter application communication – Web 2.0 and Mashups – Think client applications – Phone applications
- 6. SOAP Web Services:Example GET /InStock/GetStockPrice?StockName=HP 6
- 7. SOAP Web Services Commonlyused protocol set for Web Services The theory: However: • Structures and well • Complex and heavy defined • Especially for phone • Robust and Web 2.0 • Secure • Not the HTTP way • Designed to work on any protocol including SMTP 7
- 8. The REST designpattern Essentially what the Web always was Client/Server • Clients are separated from servers by a uniform interface. • The client–server communication is further constrained by no client Stateless context being stored on the server between requests*. • Responses must therefore, implicitly or explicitly, define themselves as Cacheable cacheable or not • A client cannot ordinarily tell whether it is connected directly to the end Layered server, or to an intermediary along the way. • A uniform interface between clients and servers simplifies and Uniform decouples the architecture. Code on demand • Servers are able to temporarily extend or customize the functionality of (optional) a client by transferring logic to it that it can execute. * The server can be stateful; this constraint merely requires that server-side state be addressable by URL as a resource. 8
- 9. RESTful Web Services Are: • A common practice for using REST design patterns for Web Services Are Not: • A well defined protocol • A set of software libraries or frameworks 9
- 10. Common RESTful WSPractices GET /InStock/HP Use of HTTP • CRUD: Create (PUT), Read (GET), Update (POST), methods to indicate Delete (DELETE) action Embedding • As part of the URL parameters in the • In headers request • Serialized as JSON in a parameter value of request body Structured output • Using JSON or XML for information serialization Custom • Use of the security token concept authentication and • Often use headers session management 10
- 11. RESTful WS Example More http://api.geonames.org/earthquakesJSON?north=44.1&south=- 9.9&east=-22.4&west=55.2&username=demo {"earthquakes": [ {"eqid":"c0001xgp","magnitude":8.8,"lng":142.369,"src":"us","datetime":"2011 -03-11 04:46:23","depth":24.4,"lat":38.322}, {"eqid":"2007hear","magnitude":8.4,"lng":101.3815,"src":"us","datetime":"200 7-09-12 09:10:26","depth":30,"lat":-4.5172}, {"eqid":"2007aqbk","magnitude":8,"lng":156.9567,"src":"us","datetime":"2007- 04-01 18:39:56","depth":10,"lat":-8.4528}, {"eqid":"2007hec6","magnitude":7.8,"lng":100.9638,"src":"us","datetime":"200 7-09-12 21:49:01","depth":10,"lat":-2.5265}, {"eqid":"a00043nx","magnitude":7.7,"lng":100.1139,"src":"us","datetime":"201 0-10-25 12:42:22","depth":20.6,"lat":-3.4841}, ... 11
- 12. More Examples It oftendoesn’t look like your typical Web (1 or 2) application Parameters in Headers None Standard Parameters/Method None Standard Authentication and Authorization 12
- 13. RESTful services Documentation • No common documentation format similar to WSDL. • WADL (Web Application Definition Languages) is a standard proposal: – Not approved – Not widely used 13
- 14. RESTful Web Servicesin the Wild About RESTful Web Services RESTful WS in the Wild Security of RESTful WS Pen-testing RESTful WS Automated security testing of RESTful WS 1 4
- 15. It’s Up andComing! 15
- 16.
- 17. RESTful Web ServicesSecurity About RESTful Web Services RESTful WS in the Wild Security of RESTful WS Pen-testing RESTful WS Automated security testing of RESTful WS 1 7
- 18. You Already KnowThis Part REST is just Web REST Security is just Web application security
- 19. Key issues tokeep in mind Some common design flaws associated with No standard security REST: Proprietary mechanism similar to • Overreliance on SSL authentication and SOAP Web Services • Session IDs used in the URL session management. (WS-*) • Using basic HTTP Authentication • Bad implementation of SSO 19
- 20. Pen Testing RESTfulWeb Services About RESTful Web Services RESTful WS in the Wild Security of RESTful WS Pen-testing RESTful WS Automated security testing of RESTful WS 2 0
- 21. Challenges Inspecting the application does not reveal application attack surface: • None Web applications • Not all Web Service functionality actually used by application • Requests are often dynamically created, Web 2.0 style. Fuzzing standard parameters not sufficient anymore • Uses none standard parameters. • Serialized inputs as JSON or XML Guidelines for fuzzing are missing • Determining initial values for fuzzing is hard for unused features • Potentially large number of parameters is inhibitive in terms of time and requires selection Custom authentication and session management breaks common cookie sharing practices. 21
- 22. Use Documentation Determine: Programing Guides Available services Use of HTTP methods Use of parameters Potential Sources: WADL Apache Mod_rewrite configuration Programing guides Configuration information Application source 22
- 23. Additional Documentation Examples WADL WCF 23
- 24. Use a Proxy Determining attack surface when no documentation exists Useful also when documentation exists to determine initial fuzzing values Extremely helpful for: • None web applications • Dynamically generated requests 24
- 25. Determining Parameters Look for none standard headers Determine if URL segments have a pattern • Numerical values • Well known templates Look for structures in parameter values • JSON, XML, YAML or other Look for irregular 404 responses • Including site specific “file not found” messages. Brute force • Change methods • Attack any URL segment 25
- 26. Automated RESTful PenTesting About RESTful Web Services RESTful WS in the Wild Security of RESTful WS Pen-testing RESTful WS Automated security testing of RESTful WS 2 6
- 27. How Does AutomatedPen-Testing works? • Determining attack surface Crawling • Historically only links based • Today employ JavaScript emulation to get dynamic requests • Parameter based: • Sending known attack vectors Attacking • Fuzzing parameters • Comparing behavior for different users or before and after login Pre- • Understanding request generation (i.e. links) • Understanding parameters requisites • Understanding session management
- 28. RESTful WS Challenges Findingattack surface by crawling Determining what elements of the request to attack Optimizing attacking time while still addressing all potential parameters. Getting initial values for fuzzing Custom authentication and session management breaks common cookie sharing practices. 28
- 29. Defining Rules • Define parameter structure for URLs. • Enable tool to use documentation & proxy discovered attack surface. • Automated discovery of rules: – Automated import of documentation sources. – Applying parameter determination techniques. 29
- 30. Thank You! Ofer Shezaf,ofr@hp.com 30