Reviewing Code for Authorization Issues - Revision history

Jmanico at 22:33, 26 February 2016

2016-02-26T22:33:14Z

Rahimjina: Review

2008-08-26T21:21:01Z

Review

Jcmax: Classic ASP technology inclusion

2008-06-07T23:55:31Z

Classic ASP technology inclusion

EoinKeary at 14:05, 3 August 2007

2007-08-03T14:05:52Z

EoinKeary: /* Hotspots */

2007-08-03T13:58:10Z

‎Hotspots

EoinKeary: .

2007-08-03T13:17:50Z

EoinKeary: /* Vulnerable Patterns for Authorization issues */

2007-08-03T13:10:33Z

‎Vulnerable Patterns for Authorization issues

EoinKeary: /* Vulnerable Patterns for Authorization issues */

2007-08-03T12:37:50Z

‎Vulnerable Patterns for Authorization issues

EoinKeary: /* Vulnerable Patterns for Authorization issues */

2007-08-03T11:10:32Z

‎Vulnerable Patterns for Authorization issues

EoinKeary: /* How to locate the potentially vulnerable code */

2007-08-01T11:19:00Z

‎How to locate the potentially vulnerable code

← Older revision		Revision as of 22:33, 26 February 2016
Line 79:		Line 79:

	[[Category:OWASP Code Review Project]]		[[Category:OWASP Code Review Project]]
−	[[Category:~~Authorization~~]]	+	[[Category:Access Control]]

@@ Line 1: / Line 1: @@
 [[OWASP Code Review Guide Table of Contents]]__TOC__
 == 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.
+Authorization issues cover a wide array of layers in a web application; from the functional authorization of a user to gain access to a particular function of the application is at the application 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.
+So what to look for when performing a code review? From an attack perspective the most common issues are a result of curiosity 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.
+Business logic errors are key areas in which to look for authorization errors.
 Areas wherein authorization checks are performed are worth looking at.
 Logical conditional cases are areas for examination such as malformed logic:
@@ Line 17: / Line 17: @@
+  }
-For classic ASP pages authorization is usually peformed using include files that contains the access control validation and restrictions. So you usually will look for something like
+For classic ASP pages authorization is usually performed using include files that contains the access control validation and restrictions. So you usually will look for something like
   <pre><!--#include file="ValidateUser.inc"--></pre>
@@ Line 23: / Line 23: @@
 == 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.
+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 obscurity 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.
+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.
 So disabling buttons on the client due to the authorization level of user shall not prevent the user from executing the action relating to the button.
@@ Line 41: / Line 41: @@
 '''ASP.NET:''' (web.config)
-The <authorization> element controls ASP.NET URL authorization and the accessability to gain access to specific folders, pages, and resources by users/web clients.
+The <authorization> element controls ASP.NET URL authorization and the accessibility to gain access to specific folders, pages, and resources by users/web clients.
 Make sure that only authenticated users are authorized to see/visit certain pages.
   <system.web>
    <authorization>
-     <deny users="?"/>   <-- Annonymous users are denied access. Users must be authenticated.
+     <deny users="?"/>   <-- Anonymous users are denied access. Users must be authenticated.
    </authorization>
   </system.web>

@@ Line 16: / Line 16: @@
     grantUser("Super_Persmissions);
+  }
 == Vulnerable Patterns for Authorization issues ==

@@ Line 30: / Line 30: @@
 By simply saving the page locally and editing the disabled=true to disabled=false and adding the absolute form action one can proceed to activate the disabled button.
-===Hotspots===
+== HotSpots ==
-'''Database:''' The account used by the application to access the database. Ensure least privilege is in effect.
+'''The Database:''' The account used by the application to access the database. Ensure least privilege is in effect.
 '''ASP.NET:''' (web.config)
@@ Line 56: / Line 56: @@
 '''Apache 1.3'''
-In Apache 1.3 there is a file called httpd. Access control can be implemented from here in the form of the Allow and Deny directives.
+In Apache 1.3 there is a file called httpd. Access control can be implemented from here in the form of the ''Allow'' and ''Deny'' directives.
 ''allow from address'' is the usage where address is the IP address or domain name to apply access to.
 Note this granularity is host level granularity.
@@ Line 68: / Line 68: @@
 Allow from owasp.org
-Above all is denied apart from owasp.org
+Above, all is denied apart from owasp.org
-To move the authorization to the user level in apache we can use the Satisfy directive.
+To move the authorization to the user level in apache we can use the ''Satisfy'' directive.
 [[Category:OWASP Code Review Project]]
 [[Category:Authorization]]

@@ Line 32: / Line 32: @@
 ===Hotspots===
-Database: The account used by the application to access the database. Ensure least privilege is in effect.
+'''Database:''' The account used by the application to access the database. Ensure least privilege is in effect.
-ASP.NET: (web.config)
+'''ASP.NET:''' (web.config)
 The <authorization> element controls ASP.NET URL authorization and the accessability to gain access to specific folders, pages, and resources by users/web clients.
@@ Line 53: / Line 53: @@
   ..........
   </system.web>
 ==Good Patterns & procedures for Authorization ==

@@ Line 24: / Line 24: @@
 So disabling buttons on the client due to the authorization level of user shall not prevent the user from executing the action relating to the button.
-  document.form.address.disabled=true;
+  document.form.adminfunction.disabled=true;
 ==Good Patterns & procedures for Authorization ==

← Older revision		Revision as of 11:10, 3 August 2007
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 ==

← Older revision		Revision as of 11:19, 1 August 2007
Line 7:		Line 7:

	==How to locate the potentially vulnerable code ==		==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 ==		== Vulnerable Patterns for Authorization issues ==