15 a4 insecure direct object reference.pptx
-
Upload
rap-payne -
Category
Technology
-
view
165 -
download
0
description
Transcript of 15 a4 insecure direct object reference.pptx
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