owasp top 10 a4 – insecure direct object reference
TRANSCRIPT
OWASP Top 10A4 – Insecure Direct Object Reference
Narudom RoongsiriwongCISSP
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]
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.
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.
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
Insecure Direct Object Web Page Query
Not Only Web Page but XML Data Island
Client Account ID
Account ID
Not Only Web Page but XML Data Island
Not Only Web Page but XML Data Island
Not Only Web Page but XML Data Island
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
Misunderstanding onInsecure 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.
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)
Temporary Mapping Value
Account Label MapID
112536 Deposit 1
115696 Current 2
Temporary
In session memory
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
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)
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
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
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 ..\
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/browse/trunk/wordlist/Injections/Traversal.txt
● Web Proxy (Burp Suite, Paros, WebScarab,OWASP: Zed Attack Proxy (ZAP))
● Encoding/Decoding tools
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
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
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
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)
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
Testing for Privilege escalation (OTG-AUTHZ-003): How to testHTTP/1.1 200 OKServer: Netscape-Enterprise/6.0Date: Wed, 1 Apr 2006 13:51:20 GMTSet-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.comCache-Control: no-cachePragma: No-cache Content-length: 247Content-Type: text/htmlExpires: Thu, 01 Jan 1970 00:00:00 GMTConnection: 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?
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
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
Common Tools for Authorization Testing
● Web Proxy (Burp Suite, Paros, WebScarab,OWASP: Zed Attack Proxy (ZAP))
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)
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)