Web Application Security | A developer's perspective - Insecure Direct Object References
Upcoming SlideShare
Loading in...5
×
 

Web Application Security | A developer's perspective - Insecure Direct Object References

on

  • 1,087 views

null Bangalore Feb 2014 meet

null Bangalore Feb 2014 meet
Author: Vamsi Krishna

Statistics

Views

Total Views
1,087
Views on SlideShare
810
Embed Views
277

Actions

Likes
0
Downloads
13
Comments
0

1 Embed 277

http://null.co.in 277

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Web Application Security | A developer's perspective - Insecure Direct Object References Web Application Security | A developer's perspective - Insecure Direct Object References Presentation Transcript

    • Web Application Security - The pitfalls and the brick walls A DEVELOPER’S PERSPECTIVE – INSECURE DIRECT OBJECT REFERENCES
    • What exactly is it about ?  Authentication and authorization  Insecure Direct Object References  Why does it happen ?  How to fix ?
    • 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
    • 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
    • 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
    • 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
    • How to fix this ?  Authorization checks for every request by the user  Using cryptographic hashes like MD5 to prevent data manipulation by user