A4 Insecure Direct Object Reference

Problem and Protection

Australian Tax Service Hacked

o  On 29/6/2000, A computer student wanted to check on his status with the new GST so he browsed to the Australian Tax Service's site and noticed a familiar number in the URL's querystring, his business tax ID (ABN)

o  He tried another ABN and saw another guy's name, address, phone, bank account, and email

o  He farmed 17,000 of these and emailed all 17,000 telling them of the breach

Apple's worst security breach o  When the iPad was released, AT&T needed

to get the customer's email from Apple given an ICC-ID so Apple stood up a service

o  It received and ICC-ID and returned an email address

Well, the user had to know a valid ICC-ID. And we made sure that the service was accessed only from an iPad. That sounds reasonable, doesn't it?

Insecure Direct Object Reference

When a developer exposes a reference to an internal object, such as a file, directory, or database key

A4 - Insecure direct object reference Attackers can get to a resource that they shouldn't know about

A8 – Failure to restrict URL access Attackers can get to a known resource without logging in

Hmmm, this sounds familiar. What's the difference between

A4 and A8?

Examples In the <industryType> it's tempting to use the <keyType>

Industry Type Key Type Banking Account number Airline Frequent flyer number

Credit card Card number Insurance Policy number

___________ ____________ ___________ ____________

* Database User ID

How attackers do it

o  They request content by manipulating the object reference

o  Trying to manipulate a portion of the URI and observing results

o  They also fiddle with the http request itself which includes: •  Cookies •  Forms fields (including hidden fields)

How we protect ourselves

o  Use hard-to-guess numbers o  Authenticate the user

Use hard-to-guess IDs

o  Use surrogate keys instead of natural ones o  Never use:

•  SSNs •  Tax IDs •  DL Numbers

http://www.tic.com/CustomerDetails/457-55-5462

o  Instead use GUIDs: http://www.tic.com/CustomerDetails

... with ... <input type="hidden" value="21EC2020-3AEA-1069-A2DD-08002B30309D" />

Or better yet, store the ID in session

But DBAs love natural keys! So what can we do if they insist on using them?

o  Go ahead and store the natural keys, but create a mapping

o  We use the natural key server-side o  But we only expose a surrogate to the user o  What surrogate? Who cares? Create a

mapping on the fly

Use an Access Reference Map

Translate keys public static class IndirectReferenceMap { public static int GetDirectReference(Guid indirectReference) { var map = (Dictionary<Guid, int>)HttpContext.Current.Session["IndirMap"]; return map[indirectReference]; } public static Guid GetIndirectReference(int directReference) { var map = (Dictionary<int, Guid>)HttpContext.Current.Session["DirMap"]; return map == null ? AddDirectReference(directReference) : map[directReference]; } private static Guid AddDirectReference(int directReference) { var indirectReference = Guid.NewGuid(); HttpContext.Current.Session["DirMap"] = new Dictionary<int, Guid> { {directReference, indirectReference } }; HttpContext.Current.Session["IndirMap"] = new Dictionary<Guid, int> { {indirectReference, directReference } }; return indirectReference; } }

Authorize the user o  If an attacker discovers a not-so-hidden page, it is

worthless if he can't authenticate o  So force the user to authenticate before going

forward o  Change this … public Customer ReadCust(int custId) { var dc = new TICDataContext(); return dc.Customers.FirstOrDefault(c=> c.CustomerID == custId); }

o  … to this: public Customer ReadCust(int custId) { if (!CanCurrentUserReadCustomer(custId)) throw new UnauthorizedAccessException(); var dc = new TICDataContext(); return dc.Customers.FirstOrDefault(c=> c.CustomerID == custId); }

Summary

o  Insecure direct references occur when attackers figure out our internal conventions and send requests with manipulated URIs

o  We protect ourselves by making our conventions very tough to predict and manipulate and by putting sensitive requests behind authorization

Further study

o  OWASP Direct Reference protection: •  http://bit.ly/OWASPDirectReference

o  Apple iPad customer data hacked: •  http://bit.ly/IPadCustomerDataExposed

o  Australian Tax Service hacked: •  http://bit.ly/AustralianTaxServiceHacked

o  OWASP DirBuster: •  Searches for and reports all direct reference

pages on your site. •  http://bit.ly/OWASPDirBuster