Authentication in ColdFusion
ColdFusion features built-in server-side file search, Adobe Flash and Adobe Flex application connectivity, web services publishing, and charting capabilities. ColdFusion is implemented on the Java platform and uses a Java 2 Enterprise Edition (J2EE) application server for many of its runtime services. ColdFusion can be configured to use an embedded J2EE server (Adobe JRun), or it can be deployed as a J2EE application on a third party J2EE application server such as Apache Tomcat, IBM WebSphere, and BEA WebLogic.
Authentication
Web and application server authentication can be thought of as two different controls (see Figure 1). Web server authentication is controlled by the web server administration console or configuration files. These controls do not need to interact with the application code to function. For example, using Apache, you modify the http.conf or .htaccess files; or for IIS, use the IIS Microsoft Management Console. Basic authentication works by sending a challenge request back to a user’s browser consisting of the protected URI. The user must then respond with the user ID and password, separated by a single colon, and encoded using base64 encoding. Application-level authentication occurs at a layer after the web server access controls have been processed. This section examines how to use ColdFusion to authenticate and authorize users to resources at the application level.
Figure 1: Web server and application server authentication occur in sequence before accessis granted to protected resources.
ColdFusion enables you to authenticate against multiple system types. These types include LDAP, text files, Databases, NTLM, Client-Side certificates via LDAP, and others via custom modules. The section below describes using these credential stores according to best practices.
Best practices
- When a user enters an invalid credential into a login page, do NOT return which item was incorrect; instead, show a generic message. For example,”Your login information was invalid!”
- Never submit login information via a GET request; always use POST.
- Use SSL to protect login page delivery and credential transmission.
- Remove dead code and client-side viewable comments from all pages.
- Set application variables in the Application.cfc file. The values you use ultimately depend on the function of your application; however, for best practices use the following:
- applicationTimeout = #CreateTimeSpan(0,8,0,0)#
- loginStorage = session
- sessionTimeout = #CreateTimeSpan(0,0,20,0)#
- sessionManagement = True
- scriptProtect = All
- setClientCookies = False (Use JSESSIONID)
- setDomainCookies = False
- name (This value is application-dependent; however, it should be set)
- Do not depend on client-side validation. Validate input parameters for typeand length on the server, using regular expressions or string functions.
- Database queries must use parameterized queries (<cfqueryparam>) or properly constructed stored procedures parameters (<cfprocparam>).
- Database connections should be created using a lower privileged account.Your application should not log into the database using sa or dbadmin.
- Hash passwords in a database or flat file using SHA-256 or greater with a random salt value for each password. For example, Hash(password + salt,”SHA-256″).
- Call StructClear(Session) to completely clear a user’s session. Issuing <cflogout> when using LoginStorage=Session removes the SESSION.cfauthorization variable from the Session scope, but does not clearthe current user’s session object.
- Prompt the user to close the browser session to ensure that header authentication information has been flushed.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.