• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OWASP Khartoum   Top 10 A4 - 7th meeting
 

OWASP Khartoum Top 10 A4 - 7th meeting

on

  • 424 views

 

Statistics

Views

Total Views
424
Views on SlideShare
422
Embed Views
2

Actions

Likes
0
Downloads
7
Comments
0

1 Embed 2

http://www.linkedin.com 2

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
  • Access Control Attacks
  • A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
  • The application uses unverified data in a SQL call that is accessing account information
  • Such code can be attacked using a string like "../../../../etc/passwd%00" using null byte injection
  • Australian Taxation Office’s GST Start Up Assistance site in 2000, where a legitimate but hostile user simply changed the ABN (a company tax id) present in the URL. The user farmed around 17,000 company details from the system, and then e-mailed each system. This was a major embarrassment to the Government of the 17,000 companies with details of his attack.
  • The best way to find out if an application is vulnerable to insecure direct object references is to verify that allobject references have appropriate defenses. To achieve this, consider:1.For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.2.If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
  • Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):1.Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPIincludes both sequential and random access reference maps that developers can use to eliminate direct object references. 2.Check access. Each use of a direct object reference from an untrustedsource must include an access control check to ensure the user is authorized for the requested object.

OWASP Khartoum   Top 10 A4 - 7th meeting OWASP Khartoum Top 10 A4 - 7th meeting Presentation Transcript

  • Insecure Direct Object Reference Obay Osman OWASP Khartoum 15 Sept 2012 Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
  • Will talk about…• Definition.• OWASP’s Rating.• Scenarios.• In the wiled.• Demo time.• Detection & Protection.• Warp Up.• Q & A. 2
  • DefinitionA direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection.Attackers can manipulate these references to access unauthorized data. 3
  • OWASP Risk Rating # 4
  • Simple Attack Scenario//BAD - DONT USE --- Reference to DB keypublic void displayInfo(){ String query = "SELECT * FROM accts WHERE account = ?";PreparedStatementpstmt=connection.prepareStatement(query , … );pstmt.setString( 1, request.getParameter("acct"));ResultSetresults = pstmt.executeQuery( );...}Attacker:http://example.com/app/accountInfo?acct=notmyacct 5
  • Simple Attack Scenario//BAD - DONT USE --- Reference to file<select name="language"><option value="fr">Français</option>…..</select> … require_once ($_REQUEST[language’]."lang.php");Attacker:../../../../etc/passwd%00 6
  • In the wield..- Australian Taxation Office.(a company tax id) - 17,000 companies affected.Methodologies: Parameter Tampering, Path Traversal, Null Byte Injection… 7
  • Let ‘s have some fun… 8
  • DetectionVerify that all object references have appropriate defenses:1.Direct references:verify the user is authorized to access the exact resource they have requested.2.Indirect references:the mapping to the direct reference must be limited to values authorized for the current user. 9
  • DetectionCode review of the application can quickly verify whether either approach is implemented safely.Testing is also effective for identifying direct object references and whether they are safe.Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe. 10
  • How to Protect YourselfProtect each user accessible object (e.g., object number, filename):1.Use per user or session indirect object references.2.Check access of direct object reference from an untrusted source, to ensure the user is authorized for the requested object. 11
  • OWASP’s RecommendationOWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.OWASP’s ESAPI Access Control API.Meet all requirements defined in OWASP’s ASVS areas V4 (Access Control). 12
  • OWASP Top 10 2010:A1 –InjectionA2 –Cross-Site Scripting (XSS)A3 –Broken Authentication and Session ManagementA4 –Insecure Direct Object ReferenceA5 –Cross Site Request Forgery (CSRF)A6 –Security Misconfiguration(NEW)A7 –Insecure Cryptographic StorageA8 –Failure to Restrict URL AccessA9 –Insufficient Transport Layer ProtectionA10 –Unvalidated Redirects and Forwards (NEW) Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
  • Ref.• OWASP Top 10-2007 on Insecure Dir Object References• ASVS requirements areas for Access control (V4)• OWASP Authentication Cheat Sheet• ESAPI Access Control API• ESAPI Access Reference Raps• OWASP Development Guide: Chapter on authentication• OWASP Testing Guide: Chapter on Authentication
  • 16