This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Reviewing Code for Authorization Issues"

From OWASP
Jump to: navigation, search
(How to locate the potentially vulnerable code)
(Vulnerable Patterns for Authorization issues)
Line 18: Line 18:
  
 
== Vulnerable Patterns for Authorization issues ==
 
== Vulnerable Patterns for Authorization issues ==
 +
One area of examination is to see if the authorization model simply relies on not displaying certain functions which the user has not authorization to use, Security by obsecurity in effect.
 +
If a crawl can be performed on the application links may be discovered which are not on the users GUI. Simple HTTP Get requests can uncover "Hidden" links.
 +
Obviously a map on the server side should be used to see if one is authorized to perform a task and we should not rely on the gui "hiding" buttons and links.
  
 
==Good Patterns & procedures for Authorization ==
 
==Good Patterns & procedures for Authorization ==

Revision as of 11:10, 3 August 2007

OWASP Code Review Guide Table of Contents

Introduction

Authorization issues cover a wide array of layers in a web application; from the functional authorization of a user to gain access to a perticular funcation of the application is at the app layer to the Database access authorization and least privilege issues at the persistence layer. So what to look for whe performing a code review. From an attack perspective the most common issues are a result of curiousity and also exploitation of vulnerabilities such as SQL injection. Example: A Database account used by an application with system/admin access upon which the application was vulnerable to SQL injection would result in a higher degree of impact rather than the same vulnerable application with a least privilege database account.

How to locate the potentially vulnerable code

Business logic errors are key areas in which to look for authorization erors. Areas wherein authorization checks are performed are worth looking at. Logical conditional cases are areas for examination such as malformed logic:

if user.equals("NormalUser"){
   grantUser(Normal_Permissions);
}else{ //user must be admin/super
  grantUser("Super_Persmissions);
}

Vulnerable Patterns for Authorization issues

One area of examination is to see if the authorization model simply relies on not displaying certain functions which the user has not authorization to use, Security by obsecurity in effect. If a crawl can be performed on the application links may be discovered which are not on the users GUI. Simple HTTP Get requests can uncover "Hidden" links. Obviously a map on the server side should be used to see if one is authorized to perform a task and we should not rely on the gui "hiding" buttons and links.

Good Patterns & procedures for Authorization