• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Web Application Security | A developer's perspective - Insecure Direct Object References
 

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

on

  • 1,054 views

null Bangalore Feb 2014 meet

null Bangalore Feb 2014 meet
Author: Vamsi Krishna

Statistics

Views

Total Views
1,054
Views on SlideShare
786
Embed Views
268

Actions

Likes
0
Downloads
11
Comments
0

1 Embed 268

http://null.co.in 268

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