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"
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…') |
|||
| Line 1: | Line 1: | ||
| − | = | + | = DRAFT CHEAT SHEET - WORK IN PROGRESS = |
This document contains rough notes and is a 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 | 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 | ||
| + | |||
| + | =Authors and Primary Editors= | ||
| + | |||
| + | |||
| + | == Other Cheatsheets == | ||
| + | {{Cheatsheet_Navigation}} | ||
| + | |||
| + | [[Category:Cheatsheets]] | ||
Revision as of 20:11, 21 January 2014
DRAFT CHEAT SHEET - 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
Authors and Primary Editors
Other Cheatsheets
OWASP Cheat Sheets Project Homepage
