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)
Line 31: Line 31:
  
 
==Related Vulnerabilities==
 
==Related Vulnerabilities==
 +
 +
*[[Reviewing Code for OS Injection]]
 +
*[[Reviewing Code for SQL Injection]]
 +
*[[Reviewing Code for Data Validation]]
 +
*[[Reviewing code for XSS issues]]
 +
*[[Reviewing Code for Error Handling]]
 +
*[[Reviewing The Secure Code Environment]]
 +
*[[Reviewing Code for Authorization Issues]]
 +
*[[Reviewing Code for Session Integrity issues]]
 +
*[[Reviewing Code for Race Conditions]]

Revision as of 15:19, 1 July 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 sucessful authentication. It coule be a realtime 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
}


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 perfromed upon every HTTP request.

Related Vulnerabilities

*Reviewing Code for OS Injection