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 "Codereview-Authorization"

From OWASP
Jump to: navigation, search
(Related Vulnerabilities)
m (Review - spelling etc)
Line 6: Line 6:
 
Authorisation is key in multiuser environments where user data should be segregated. different clients/users should not see other clients data (Horizontal authorisation). Authorisation can also be used to restrict functionality to a subset of users. "super users" would have extra admin functionality a "regular user" would not have access to (Vertical authorisation).
 
Authorisation is key in multiuser environments where user data should be segregated. different clients/users should not see other clients data (Horizontal authorisation). Authorisation can also be used to restrict functionality to a subset of users. "super users" would have extra admin functionality a "regular user" would not have access to (Vertical authorisation).
  
Authorisation is a very bespoke area in application development. It can be implemented via a lookup table in a users session which is loaded upon sucessful authentication. It coule be a realtime interrogation of a backend LDAP or database system upon each request.  
+
Authorisation is a very bespoke area in application development. It can be implemented via a lookup table in a users session which is loaded upon successful authentication. It could be a real-time interrogation of a backend LDAP or database system upon each request.  
  
 
==Good Example==
 
==Good Example==
Line 29: Line 29:
  
 
  Building the GUI based on the users authorisation. "If he cant see the control we wont be able to use it"  
 
  Building the GUI based on the users authorisation. "If he cant see the control we wont be able to use it"  
- Common enough error. If a user has the URL the functionality can still be called. This is due to no authorisation check being perfromed upon every HTTP request.
+
- Common enough error. If a user has the URL the functionality can still be called. This is due to no authorisation check being performed upon every HTTP request.
  
 
==Related Vulnerabilities==
 
==Related Vulnerabilities==
  
 
*[[Reviewing Code for OS Injection]]
 
*[[Reviewing Code for OS Injection]]
  Operating system injection can be used to totally ignore authorisation constraints. Access to the uderlaying host is a key objective of system breach. The application is simply a conduit for access to data.
+
  Operating system injection can be used to totally ignore authorisation constraints. Access to the underlying host is a key objective of system breach. The application is simply a conduit for access to data.
  
 
*[[Reviewing Code for SQL Injection]]
 
*[[Reviewing Code for SQL Injection]]
  SQL injection can be used to circumvent authorisation. Again, systems are breached to obtain underlaying data, they are not breached for the applications themselves. SQL injection is in essence accessing the data via an "out of band" channel not intended by the application.
+
  SQL injection can be used to circumvent authorisation. Again, systems are breached to obtain underlying data, they are not breached for the applications themselves. SQL injection is in essence accessing the data via an "out of band" channel not intended by the application.
  
 
*[[Reviewing Code for Data Validation]]
 
*[[Reviewing Code for Data Validation]]

Revision as of 20:26, 26 August 2008

OWASP Code Review Guide Table of Contents

Introduction

Authorisation is key in multiuser environments where user data should be segregated. different clients/users should not see other clients data (Horizontal authorisation). Authorisation can also be used to restrict functionality to a subset of users. "super users" would have extra admin functionality a "regular user" would not have access to (Vertical authorisation).

Authorisation is a very bespoke area in application development. It can be implemented via a lookup table in a users session which is loaded upon successful authentication. It could be a real-time interrogation of a backend LDAP or database system upon each request.

Good Example

Check authorisation upon every user request.


String action = request.getParameter("action")
if (action == "doStuff"){
  boolean permit = session.authTable.isAuthorised(action); // check table if authoirsed to do action
}
if (permit){
 doStuff();
}else{
 throw new (InvalidRequestException("Unauthorised request"); // inform user of no authorisation
 session.invalidate(); // Kill session
}

Authorisation being performed upon all requests from external entities

Authorisation.jpg

Bad Example

Building the GUI based on the users authorisation. "If he cant see the control we wont be able to use it" 

- Common enough error. If a user has the URL the functionality can still be called. This is due to no authorisation check being performed upon every HTTP request.

Related Vulnerabilities

Operating system injection can be used to totally ignore authorisation constraints. Access to the underlying host is a key objective of system breach. The application is simply a conduit for access to data.
SQL injection can be used to circumvent authorisation. Again, systems are breached to obtain underlying data, they are not breached for the applications themselves. SQL injection is in essence accessing the data via an "out of band" channel not intended by the application.
The root of all evil - Need we say more :)

Insecure class files, folders in deployment may be used to attack an application outside the actual application itself.
Impersonation can obviously be used to gain unauthorised privilege.

In a multi user, multi-threaded environment thread safety is important as one may obtain another individuals session in error.