Web Application Security | A developer's perspective - Insecure Direct Object References
1. Web Application
Security - The pitfalls
and the brick walls
A DEVELOPER’S PERSPECTIVE – INSECURE DIRECT OBJECT REFERENCES
2. What exactly is it about ?
Authentication and authorization
Insecure Direct Object References
Why does it happen ?
How to fix ?
3. Authentication - Who are you ?
Authentication is the process of identifying you.
It’s the first step in securing any application or a system.
Usual process follows by the user explicitly telling the system who he
is by providing his login credentials
4. Authorization – What are you ?
Authorization is the process of identifying what permissions the
authenticated user has in the current system
Obviously, it starts after authentication
Authorization is usually initiated by the system/application on behalf
of a authenticated user, by fetching his permission set from a data
store
5. Insecure Direct Object References
It’s a design flaw, where the system designer/developer expects the
user to follow the rules set by the system, without any infrastructure
to protect sensitive assets and data, when the user does not go by
the rules
This vulnerability is usually exploited by an already authenticated
user with some level of access to the system
An authenticated user may exploit a vulnerable system to access
sensitive data by changing the parameters passed to the server, to
the one’s he is trying to access
6. Why does it happen ?
A thought process generally referred to as Security through obscurity
Fear of cost involved in authorizing the user on every request
General lack of awareness and oversight
7. How to fix this ?
Authorization checks for every request by the user
Using cryptographic hashes like MD5 to prevent data manipulation
by user