Insecure Direct Object Reference Prevention Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:37:14Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T12:49:36Z

Migration to GitHub

Show changes

Dominique RIGHETTO: Article complete refactoring

2018-01-14T09:14:19Z

Article complete refactoring

Show changes

Jmanico at 20:11, 21 January 2014

2014-01-21T20:11:55Z

Jmanico: 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…'

2009-10-12T12:51:50Z

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…'

New page

== WORK IN PROGRESS ==

This document contains rough notes and is a work in progress.

== Introduction ==

[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

← Older revision		Revision as of 14:37, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.md Insecure Direct Object Reference Prevention Cheat Sheet] to see the latest version of the cheat sheet.	+	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.

@@ Line 1: / Line 1: @@
-== WORK IN PROGRESS ==
+= DRAFT CHEAT SHEET - WORK IN PROGRESS =
 This document contains rough notes and is a work in progress.
@@ Line 18: / Line 18: @@
 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