insecuredirectobjectreferences

24
Melissa Canazon Object References IT6873 Information Security Seminar – Fall 2014 How do you refer to secure information?

Upload: macanazon

Post on 19-Jun-2015

280 views

Category:

Technology


0 download

DESCRIPTION

OWASP Insecure Direct Object References, URL manipulation, path and directory traversal, user input is evil

TRANSCRIPT

  • 1. Insecure DirectObject ReferencesMelissa CanazonHow do you refer to secureinformation?IT6873 Information SecuritySeminar Fall 2014

2. A4-Insecure Direct ObjectReferencesA direct object reference occurs when a developerexposes a reference to an internal implementationobject, such as a file, directory, or database key. Withoutan access control check or other protection, attackerscan manipulate these references to access unauthorizeddata.~ OWASP* Formally defined by OWASP, but what does this mean? 3. Path to UnderstandingDefining ObjectsDefining ReferencesDefining InsecureWhat does insecure direct object reference mean?- examplesHow can it be used?PreventionTopic 1Topic 2Topic 3Topic 4Topic 5Topic 6Topic 7How is it detected? 4. Definition: Objects 5. OBJECTSdata, information, files, images, video, resource, etc.*can be stored and retrieved in either an unprocessed orprocessed format 6. Definition: References 7. REFERRING TO OBJECTSDIRECTORYwww.directory.comOBJECT 1www.directory.com/object1OBJECT 2www.directory.com/object2OBJECT 3www.directory.com/object3 8. Definition: InsecureAuthentication vs. Authorization 9. AUTHENTICATION vs AUTHORIZATIONCERTIFIEDAUTHENTICUSER 10. Defining Insecure Direct Object Reference 11. Object1www.some.com/access/authorizeduser/object2www.some.com/access/unauthorizeduser/object1 12. How Can You Use Direct Object References? inurl: admin inurl:cgi filetype: pdf auth_user_file.txt index of ftp +.mdb allinurl:/cgi-bin/+mailto 13. How Can You Use Direct Object References? 14. How Can You Use Direct Object References?dot dot slash.../ Moving down the directory Some apps prevent this type of traversal,so alternately: %2e%2e%2f which translates to ../ %2e%2e/ which translates to ../ ..%2f which translates to ../ %2e%2e%5c which translates to .. 15. Detection 16. PreventionJust a friendly reminder to developers:INPUT IS EVIL! 17. INPUT IS EVILInput can bemalicious,always validateit before youtrust it! 18. User inputDirectReferenceUSERSESSIONReference MappingIndirectResourceReferenceWeb appsendsresourceUser receivesresource &indirectreferenceWeb appreceivesrequestReferenceMapGenerated 19. Spoiler Alert!Access Control 20. Check out A7-Missing FunctionLevel AccessControl!Most webapplications verifyfunction levelaccess rightsbefore making thatfunctionalityvisible in the UI.However,applications needto perform thesame accesscontrol checks onthe server wheneach function isaccessed.If requests are notverified, attackerswill be able toforge requests inorder to accessfunctionalitywithout properauthorization.ACCESS CONTROL 21. Check out A10-UnvalidatedRedirects andForwards!Applicationsfrequently redirectusers to otherpages, or useinternal forwardsin a similarmanner.ACCESS CONTROLSometimes thetarget page isspecified in anun-validatedparameter,allowingattackers tochoose thedestinationpage.Unsafe forwardsmay allow accesscontrol bypass.What ifattackers canaccess internalonly functions? 22. OWASP Top 10 Threats and Mitigationshttp://michaelpeters.org/quiz/I challenge you to take the quizand share your thoughts!Post in the discussion board!Thanks to Albena and Aaron forbeing my resource reviewers! 23. REFERENCES1. CWE-22: Improper Limitation of a Pathname to a Restricted Directory. 30 July 2014. CWECommon Weakness Enumeration. Retrieved from: http://cwe.mitre.org/data/definitions/22.html2. CWE-639: Authorization Bypass Through User-Controlled Key. 30 July 2014. CWE CommonWeakness Enumeration. Retrieved from: http://cwe.mitre.org/data/definitions/639.html3. CWE-706: Use of incorrectly resolved name or reference. 30 July 2014. CWE Common WeaknessEnumeration. Retrieved from: http://cwe.mitre.org/data/definitions/706.html4. Hacking Websites Using Directory Traversal Attack. September 2012. HackingLoops.com.Retrieved from: http://www.hackingloops.com/2012/09/hacking-websites-using-directory-traversal-attacks.html5. Melton, John. 10 May 2010. The OWASP Top 10 and ESAPI Part 4 Insecure Direct ObjectReferences. Retrieved from: http://www.jtmelton.com/2010/05/10/the-owasp-top-ten-and-esapi-part-5-insecure-direct-object-reference/6. Mukherjee, Sumantro. 2 April 2013. Google Hacking: A Must Read Article. Hackshark. Retrievedfrom: http://hackshark.com/?p=1058#axzz3EgMnLtXk7. OWASP. 8 AUGUST 2014. Testing for Insecure Direct Object References. Retrieved from:https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)8. OWASP. 14 June 2013. Top 10 2013-A4-Insecure Direct Object References. Retrieved from:https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References9. Peters, Michael. 25 December 2012. Pop Quiz! Test your OWASP knowledge and earn credit.MichaelPeters.org. Retrieved from: http://michaelpeters.org/quiz/10. Redkar, Vinesh. 13 June 2013. NOKIA Insecure Direct Object Reference. AVs3curity. Retrievedfrom: http://avs3curity.blogspot.com/2013/06/nokia-insecure-direct-object-reference.html