DIRECT OBJECT REFERENCE
DIRECT OBJECT REFERENCE
OWASP regularly compiles a list
of the top 10 security
vulnerabilities
#4 on this list is the Direct
Object Reference
DIRECT OBJECT REFERENCE
This did not even make the list
prior to 2004
Web applications have become more
complicated with different parts
of the application and different
data accessible to each user
DIRECT OBJECT REFERENCE
This vulnerability exists in an
application if it exposes an internal
implementation detail to the user
DIRECT OBJECT REFERENCE
This vulnerability exists in an
application if it exposes an internal
implementation detail to the user
This could be a database key, a file
name, the name of an object -
anything
DIRECT OBJECT REFERENCE
Let’s take an example
A site allows users to send
messages to each other
DIRECT OBJECT REFERENCE
All messages are stored in a
database - a simple one like this
ID FROM TO MESSAGE
103 a@gmail.com jan@gmail.com Hi how are you?
104 wer123@yahoo.com jeff@email.com Shall I see you in an hour?
This is a long message, hope
105 toby@hotmail.com glenn@hotmail.com
you’re doing well..
106 jane@gmail.com verna@hotmail.com Thank you for your help!
DIRECT OBJECT REFERENCE
ID FROM TO MESSAGE
103 a@gmail.com jan@gmail.com Hi how are you?
104 wer123@yahoo.com jeff@email.com Shall I see you in an hour?
This is a long message, hope
105 toby@hotmail.com glenn@hotmail.com
you’re doing well..
106 jane@gmail.com verna@hotmail.com Thank you for your help!
A message id is a unique auto
incremented value for every message,
used to identify a message
DIRECT OBJECT REFERENCE
ID FROM TO MESSAGE
103 a@gmail.com jan@gmail.com Hi how are you?
104 wer123@yahoo.com jeff@email.com Shall I see you in an hour?
This is a long message, hope
105 toby@hotmail.com glenn@hotmail.com
you’re doing well..
106 jane@gmail.com verna@hotmail.com Thank you for your help!
These are from and to fields, other
fields like timestamp etc have been left
out for simplicity
DIRECT OBJECT REFERENCE
ID FROM TO MESSAGE
103 a@gmail.com jan@gmail.com Hi how are you?
104 wer123@yahoo.com jeff@email.com Shall I see you in an hour?
This is a long message, hope
105 toby@hotmail.com glenn@hotmail.com
you’re doing well..
106 jane@gmail.com verna@hotmail.com Thank you for your help!
And actual message contents
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
This is the URL to access one particular
message
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
If the user is not logged in, this URL
forces him to the login page for the site
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
On logging in a session variable is set
up which stores the user id
This indicates that the user has logged
in for this session
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
The message id is used to uniquely
identify the message to view
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
154
This should allow the user to view the
message with the unique id 154
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
154
As the user goes through the messages
in his inbox - the message id in the URL
changes to reflect the different
messages he has received
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
154
But what if message id 154 did not
have the current user in either its from
or to fields?
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
154
We’ve basically allowed a user to view
messages in our database which do not
belong to him!
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
154
The message id is an internal
implementation detail of the system,
and the URL exposes this to the user
DIRECT OBJECT REFERENCE
http://trustedmail.com/messages/?id=102
154
This is a direct object reference to an
internal object
DIRECT OBJECT REFERENCE
Here is an example from the real
world - this is something which
actually happened
DIRECT OBJECT REFERENCE
Some years ago a financial company
ended up inadvertently exposing
financial data of its members
to other members who were not
authorized to view it
DIRECT OBJECT REFERENCE
Say you were logged and
authenticated to your pension account
http://www.trustedfinancialsite.com/
viewdetails.php/?account_id=1234
This page showed you all details
of your retirement funds
DIRECT OBJECT REFERENCE
http://www.trustedfinancialsite.com/
viewdetails.php/?account_id=1234
The account you view is
specified by this URL parameter
DIRECT OBJECT REFERENCE
http://www.trustedfinancialsite.com/
viewdetails.php/?account_id=1234
Now if you edited the URL
parameter to change the
account id
DIRECT OBJECT REFERENCE
http://www.trustedfinancialsite.com/
8123
viewdetails.php/?account_id=1234
The company’s site let you access
the details of the other account!
DIRECT OBJECT REFERENCE
http://www.trustedfinancialsite.com/
8123
viewdetails.php/?account_id=1234
There was no additional check to
see whether you were authorized to
view those account details!
DIRECT OBJECT REFERENCE
http://www.trustedfinancialsite.com/
8123
viewdetails.php/?account_id=1234
The account id is an internal
implementation detail of the code
DIRECT OBJECT REFERENCE
http://www.trustedfinancialsite.com/
8123
viewdetails.php/?account_id=1234
Exposing this information
compromised millions of accounts
linked to that financial company
DIRECT OBJECT REFERENCE
Mitigation
DIRECT OBJECT REFERENCE
Mitigation
1. Authorization
2. Indirection Layer
3. Randomized Identifiers
DIRECT OBJECT REFERENCE
Mitigation - Authorization
A direct object reference
vulnerability of this kind has a
basic authorization problem
DIRECT OBJECT REFERENCE
Mitigation - Authorization
Authorization refers to what a
user has access to
what data,
what components of a site
DIRECT OBJECT REFERENCE
Mitigation - Authorization
In the messages example or in the
pension account example a simple
check would have sufficed for
authorization
DIRECT OBJECT REFERENCE
Mitigation - Authorization
Does the message have the user in
the to, from or cc field?
Is the current user the owner of
that pension account?
DIRECT OBJECT REFERENCE
Mitigation
1. Authorization
2. Indirection Layer
3. Randomized Identifiers
DIRECT OBJECT REFERENCE
Mitigation - Indirection Layer
Internal ids and objects should not
be exposed to the user directly
Instead a separate layer can map the
internal ids to externally visible ids
DIRECT OBJECT REFERENCE
Mitigation - Indirection Layer
Instead a separate layer can map the
internal ids to externally visible ids
LOCAL PER-USER MAPPING ID
0 103
1 104
2 105
3 106
DIRECT OBJECT REFERENCE
Mitigation - Indirection Layer
LOCAL PER-USER MAPPING ID
0 103
1 104
2 105
3 106
Each user will have a specific id
which maps to the message id
DIRECT OBJECT REFERENCE
Mitigation - Indirection Layer
LOCAL PER-USER MAPPING ID
0 103
1 104
2 105
3 106
The keys of this map is what will
display in the URL parameter
DIRECT OBJECT REFERENCE
Mitigation - Indirection Layer
LOCAL PER-USER MAPPING ID
0 103
1 104
2 105
3 106
A map like this should be generated
for every user
DIRECT OBJECT REFERENCE
Mitigation - Indirection Layer
LOCAL PER-USER MAPPING ID
0 103
1 104
2 105
3 106
So no user can even try and access
messages he is not authorized to
DIRECT OBJECT REFERENCE
Mitigation
1. Authorization
2. Indirection Layer
3. Randomized Identifiers
DIRECT OBJECT REFERENCE
Mitigation - Randomized Identifiers
Instead of using predictable, auto-
incremented ids the identifiers
could also be randomly generated
DIRECT OBJECT REFERENCE
Mitigation - Randomized Identifiers
This by itself is not enough
mitigation but can be used along
with the other techniques
DIRECT OBJECT REFERENCE
Mitigation
1. Authorization
2. Indirection Layer
3. Randomized Identifiers
