This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Insecure Direct Object Reference Prevention Cheat Sheet"

From OWASP
Jump to: navigation, search
m (Created page with '== WORK IN PROGRESS == This document contains rough notes and is a work in progress. == Introduction == [jeff williams] Direct Object Reference is fundamentally a Access Contr…')
 
m (Point to the official site)
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
== WORK IN PROGRESS ==
+
__NOTOC__
 +
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
  
−
This document contains rough notes and is a work in progress.
+
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
  
−
== Introduction ==
+
Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html Insecure Direct Object Reference Prevention Cheat Sheet] to see the latest version of the cheat sheet.
−
 
 
−
[jeff williams]
 
−
Direct Object Reference is fundamentally a Access Control problem. We split it out to emphasize the difference between URL access control and data layer access control.  You can’t do anything about the data-layer problems with URL access control.  And they’re not really input validation problems either.  But we see DOR manipulation all the time.  If we list only “Messed-up from the Floor-up Access Control” then people will probably only put in SiteMinder or JEE declarative access control on URLs and call it a day.  That’s what we’re trying to avoid.
 
−
 
 
−
[eric sheridan]
 
−
An object reference map is first populated with a list of authorized values which are temporarily stored in the session. When the user requests a field (ex: color=654321), the application does a lookup in this map from the session to determine the appropriate column name. If the value does not exist in this limited map, the user is not authorized. Reference maps should not be global (i.e. include every possible value), they are temporary maps/dictionaries that are only ever populated with authorized values.
 
−
 
 
−
== Architectural Options ==
 
−
 
 
−
“A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter.”
 
−
 
 
−
I’m “down” with DOR’s for files, directories, etc. But not so much for ALL databases primary keys. That’s just insane, like you are suggesting. I think that anytime database primary keys are exposed, an access control rule is required. There is no way to practically DOR all database primary keys in a real enterprise or post-enterprise system.
 
−
 
 
−
But, suppose a user has a list of accounts, like a bank where database id 23456 is their checking account. I’d DOR that in a heartbeat. You need to be prudent about this
 

Latest revision as of 14:37, 15 July 2019

Cheatsheets-header.jpg

The Cheat Sheet Series project has been moved to GitHub!

Please visit Insecure Direct Object Reference Prevention Cheat Sheet to see the latest version of the cheat sheet.

Retrieved from "https://wiki.owasp.org/index.php?title=Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet&oldid=253060"