Guide to Authorization - Revision history

Jmanico: merging access control content

2016-06-01T23:38:27Z

merging access control content

Show changes

Jmanico: suggest making reauth and idle separate discussions

2016-05-22T16:59:27Z

suggest making reauth and idle separate discussions

Jmanico: /* Relevant COBIT Topics */

2016-05-22T16:58:20Z

‎Relevant COBIT Topics

Jmanico: /* How to protect yourself */

2016-05-22T16:57:44Z

‎How to protect yourself

Jmanico: /* How to protect yourself */

2016-05-22T16:57:20Z

‎How to protect yourself

Jmanico: /* Best Practices in Action */

2016-05-22T16:51:25Z

‎Best Practices in Action

Jmanico: /* Best Practices in Action */

2016-05-22T16:51:09Z

‎Best Practices in Action

MediaWiki spam cleanup: Reverting to last version not containing links to www.textletoorc4td.com

2009-05-27T18:27:34Z

Reverting to last version not containing links to www.textletoorc4td.com

Show changes

Deleted user at 17:37, 21 May 2009

2009-05-21T17:37:46Z

Show changes

KirstenS: /* How to protect yourself */

2009-03-03T18:13:48Z

‎How to protect yourself

@@ Line 170: / Line 170: @@
 * Do not store sensitive static content in web-accessible directory paths. Rather, store this content in non-web accessible directories and proxy access to this content through a handler that will implement proper authorization, logging, and other security functions. On the ASP.NET platform, the HTTPResponse.WriteFile() method can be used to implement this functionality. NOTE: Whenever accessing the file system from web-facing code be sure to guard against potential injection attacks.
-==Reauthorization for high value activities or after idle out ==
+==Reauthorization for high value activities ==
 ===How to determine if you are vulnerable ===

← Older revision		Revision as of 16:58, 22 May 2016
Line 14:		Line 14:

	All applications.		All applications.
−
−	~~==Relevant COBIT Topics ==~~
−
−	~~DS5 – All sections should be reviewed. This section covers nearly all COBIT detailed control objectives.~~

	==Best Practices ==		==Best Practices ==

@@ Line 239: / Line 239: @@
   if ( authenticated ) {
-  $_SESSION[‘authlevel’] = X_USER; 	// X_USER is defined elsewhere as meaning, the user is authorized
+  // X_USER is defined elsewhere as meaning, the user is authorized
+  }

@@ Line 226: / Line 226: @@
 '''Java'''
-<pre>
+ if ( authenticated ) {
+ request.getSession(true).setValue(“AUTHLEVEL”) = X_USER;
 if ( authenticated ) {
 '''.NET (C#)'''
-<pre>
+ if ( authenticated ) {
+ Session[“AUTHLEVEL”] = X_USER;
 if ( authenticated ) {
 '''PHP'''
-<pre>
+ if ( authenticated ) {
+ $_SESSION[‘authlevel’] = X_USER; 	// X_USER is defined elsewhere as meaning, the user is authorized
 if ( authenticated ) {
 Check your application:

@@ Line 33: / Line 33: @@
   <cfargument name="strUserName" required="true" type="string">
   <cfargument name="strPassword" required="true" type="string">
-<cfset var retargs = StructNew()>
+ <cfset var retargs = StructNew()>
-<cfif IsValid("regex", strUserName, "[A-Za-z0-9%]*") AND IsValid("regex", strPassword, "[A-Za-z0-9%]*")>
+ <cfif IsValid("regex", strUserName, "[A-Za-z0-9%]*") AND IsValid("regex", strPassword, "[A-Za-z0-9%]*")>
-<cfquery name="loginQuery" dataSource="#Request.DSN#" >
+ <cfquery name="loginQuery" dataSource="#Request.DSN#" >
   SELECT userid, hashed_password, salt
   FROM UserTable

@@ Line 29: / Line 29: @@
 Continuing with the previous code, the following extends the code in the dbLogin method of the auth.cfc to return the user’s roles. The roles are passed to the <cfloginuser> to provide authentication to ColdFusion’s built-in login structure. The roles are also used to provide authorization to ColdFusion Components.
-<pre>
+ Auth.cfc
-Auth.cfc
+ <cffunction name="dblogin" access="public" output="false" returntype="struct">
+ <cfargument name="strUserName" required="true" type="string">
-<cffunction name="dblogin" access="public" output="false" returntype="struct">
+ <cfargument name="strPassword" required="true" type="string">
 <cfset var retargs = StructNew()>
 <cfif IsValid("regex", strUserName, "[A-Za-z0-9%]*") AND IsValid("regex", strPassword, "[A-Za-z0-9%]*")>
 <cfquery name="loginQuery" dataSource="#Request.DSN#" >
+ SELECT userid, hashed_password, salt
-SELECT userid, hashed_password, salt
+ FROM UserTable
+ WHERE UserName =
-FROM UserTable
+ <cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">
+ </cfquery>
-WHERE UserName =
+ <cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>
+ <cfset retargs.authenticated="YES">
-<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">
+ <cfset Session.UserName = strUserName>
+ <!-- Add code to get roles from database -->
-</cfquery>
+ <cfquery name="authQuery" dataSource="#Request.DSN#" >
+ SELECT roles.role
-<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>
+ FROM roles INNER JOIN (users INNER JOIN userroles ON users.userid = userroles.userid) ON roles.roleid = userroles.roleid
+ WHERE (((users.usersid)='<cfqueryparam value=“#loginQuery.userid#” cfsqltype=”CF_SQL_INTEGER”>'))
-<cfset retargs.authenticated="YES">
+ </cfquery>
+ <cfif authQuery.recordCount>
-<cfset Session.UserName = strUserName>
+ <cfset retargs.roles = valueList(authQuery.role)>
+ <cfelse>
-<!-- Add code to get roles from database -->
+ <cfset retargs.roles = “user”>
+ </cfif>
-<cfquery name="authQuery" dataSource="#Request.DSN#" >
+ <cfelse>
+ <cfset retargs.authenticated="NO">
-SELECT roles.role
+ </cfif>
+ <cfelse>
-FROM roles INNER JOIN (users INNER JOIN userroles ON users.userid = userroles.userid) ON roles.roleid = userroles.roleid
+ <cfset retargs.authenticated="NO">
+ </cfif> ---><cfset retargs.authenticated = true><cfset retargs.roles = "Admin">
-WHERE (((users.usersid)='<cfqueryparam value=“#loginQuery.userid#” cfsqltype=”CF_SQL_INTEGER”>'))
+ <cfreturn retargs>
+ </cffunction>
 ==Principle of least privilege ==

@@ Line 136: / Line 136: @@
 * Business user accounts should not be administrator accounts and vice versa. Separate accounts should be used to perform these different sets of tasks even if the same user needs to be able to perform tasks in both realms.
-* Web applications should access the database through one or more limited accounts that do not have schema-modification privileges unless required. If the web application requires the ability to modify the database schema then the design should be analyzed to determine if and why functionality must be implemented in such a potentially hazardous manner.
+* Web applications should access the database through one or more limited accounts that do not have schema-modification privileges unless required. If the web application requires the ability to modify the database schema, then the design should be analyzed to determine if and why functionality must be implemented in such a potentially hazardous manner.
 * Database access should be performed through parameterized stored procedures (or similar) to allow all table access to be revoked (i.e. select, drop, update, insert, etc). This should be done using a low privilege database account. This account should not hold any SQL roles above “user” (or similar).