Advanced Macromedia ColdFusion MX 7 Application Development

The following sections provide additional best practice information for all ColdFusion environments. The previous sections describe configuration issues specific to shared and hosted environments. The security issues in the following section also affect dedicated environments. These issues are not specific to any operating system platform or web server configuration.

Running ColdFusion as a User

ColdFusion services run as the privileged local system account user by default on Windows systems. This may provide a higher level of access to system resources than security policies permit. Administrators may need to change the user account for the ColdFusion services. The ColdFusion installer requests a user account for ColdFusion on Unix-based systems, so this is rarely a problem. To run ColdFusion as a specific user account, first create the user account (adding it to the appropriate groups). Apply the following permissions for the ColdFusion user account:

NOTE

The following instructions refer to ColdFusion installations. For previous ColdFusion installations see TechNote 17279, Running ColdFusion as a specific user at http://www.macromedia.com/go/tn_17279.

  • Modify (or Read & Execute, List Folder Contents, Write, and Delete on Windows; Read, Write, Executre, and Delete or MOD 777 on Unix) permissions on the entire cf_root directory structure

  • Read and Execute permissions on all web content (.cfm, .cfc, images, etc.)

On Windows, give the ColdFusion user the following User Rights Assignments:

  • Log on as a Service (should be set)

  • Deny log on locally

  • Deny log on through Terminal Services

Use the following steps to start ColdFusion with the new account:

TIP

Ensure the file permissions are set before starting ColdFusion with the new account.

Windows 2000/XP/2003

1.

Open the Services applet: select Start menu > Settings > Control Panel > Administrative Tools > Services.

2.

Double-click the "ColdFusion MX 7 Application Server" service.

3.

On the General tab, click Stop to stop the service if it is running.

4.

On the Log On tab, select the radio next to "This account:"

5.

Browse to the ColdFusion user account.

6.

Enter and confirm the password for the ColdFusion user account as shown in Figure 10.12.

Figure 10.12. Enter the username and password for the ColdFusion user account.

7.

Click Apply.

8.

On the General tab, click Start.

9.

Click OK to close.

Unix-systems (Unix, Linux, and HP-UX)

1.

Stop ColdFusion if it is running.

2.

Back up the cf_root/bin/coldfusion file.

3.

Edit the cf_root/bin/coldfusion file and replace the RUNTIME_USER entry with the name of the new ColdFusion account.

4.

Save the file.

5.

Start ColdFusion.

Macromedia Flash Remoting Integration

ColdFusion ships with an integrated Macromedia Flash Remoting gateway (http://www.macromedia.com/software/flashremoting/). This allows Macromedia Flash components access to ColdFusion objects. ColdFusion MX 7 makes some configuration changes to the gateway. These changes are configurable in the gateway-config.xml file found in cf_root/wwwroot/WEB-INF (Server configuration) or cf_webapp_root/WEB-INF (Multiserver and J2EE configurations).

Flash Remoting Service Adapters

There are several Flash Remoting service adapters, but only the following adapters are enabled by default in ColdFusion MX 7: Pageable Resultset (PageableResultsetAdapter), ColdFusion (ColdFusionAdapter), ColdFusion Component (CFCAdapter), and ColdFusion Server-Side ActionScript (CFSSASAdapter). One of the fundamental changes made in ColdFusion MX 7 was the disabling of the Flash Remoting Gateway servlet service adapter. This adapter enabled the Flash Remoting Gateway servlet URL ( http://localhost/flashservices/gateway), which returned a blank screen and signified the proper configuration of Flash Remoting for ColdFusion. Macromedia deemed this a security hole and chose to disable it in CFMX 7. This may catch some developers unaware, and when they access the URL they'll get a 404 in the browser and the following error logged:

[Flash Remoting MX]->Request received was not Flash-based (not of the binary AMF protocol)

Macromedia also disabled the Flash Remoting ColdFusion Web Services service adapter. This adapter provided Flash Remoting access to ColdFusion Web services. ColdFusion disabled this adapter by default, but it was configurable by the DISABLE_CFWS_ADAPTERS property in the web.xml file. This property is removed in CFMX 7, however, and replaced by the coldfusion .flash.adapter.CFWSAdapter in the gateway-config.xml file.

You can enable these service adapters (or any others) by uncommenting them in the gateway- config.xml. To enable the Flash Remoting Gateway servlet, uncomment the following line in the <service-adapters> section:

<adapter type="servlet">flashgateway.adapter.java.ServletAdapter</adapter>

To enable the ColdFusion Web Services adapter, uncomment the following line:

<adapter>coldfusion.flash.adapter.CFWSAdapter</adapter>

Flash Remoting Whitelist

A whitelist is a list of remote resources accessible via Flash Remoting. Administrators can use the <whitelist> entry to restrict access to certain ColdFusion-based services. ColdFusion-based services are actually directories that are treated like Java packages; for example. the C:\InetPub\wwwroot\ows\Blackbox directory is specified as ows.Blackbox.*. The default whitelist enables access to all ColdFusion-based services (or *). Administrators should change this default setting in order to lock down Flash Remoting.

To add whitelist restrictions, modify the <source> attribute of the <whitelist> entry in the <security> section of gateway-config.xml. You can specify more than one <source> attribute. Here is the syntax:

<whitelist> <source>ows.Blackbox.*</source> </whitelist>

Macromedia Flex Whitelist

The ColdFusion MX 7 Flash-based forms are powered by the Macromedia Flex server (http://www.macromedia.com/software/flex/). Flex empowers enterprise application programmers to develop Rich Internet Applications (RIAs). It is the engine that turns forms created with <cfform> into Flash- and XML-based forms. Like the Flash Remoting gateway, the Flex server has a configurable whitelist that specifies the remote resources available to the Flex proxy. The <whitelist> entry is found in the <security> section of the cfform-gateway-config.xml file. This file is also found in cf_root/wwwroot/WEB-INF (Server configuration) and cf_webapp_root/WEB-INF (Multiserver/J2EE configuration). Administrators can use the Flash Remoting whitelist syntax for the Flex whitelist:

<whitelist> <source>ows.Blackbox.*</source> </whitelist>

Disabling JSP Functionality

ColdFusion includes support for JavaServer Pages (JSP) functionality by leveraging the underlying J2EE application server. However, Cold Fusion's security sandboxes cannot restrict access to JSP functionality. For this reason, Macromedia recommends disabling JSP support in multi-hosted environments (see security bulletin MPSB02-04 at http://www.macromedia.com/devnet/security/security_zone/mpsb02-04.html.)

Use the following steps to disable JSP functionality within ColdFusion:

1.

Stop ColdFusion.

2.

Back up the default-web.xml file. This is located in cf_root\runtime\servers\coldfusion\SERVER-INF (Server configuration) and cf_root\runtime\servers\default\SERVER-INF (Multiserver configuration).

3.

Open the original file in a text editor, and delete or comment out the servlet-mapping entry for *.jsp as follows:

<!-- <servlet-mapping> <servlet-name>JSPServlet</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping> -->

4.

Save and close the file.

5.

Restart ColdFusion.

Securing the CFIDE Directory

The CFIDE directory path is known as the ColdFusion administration directory. The default path to CFIDE is webroot/CFIDE for external web server integration and cf_root/wwwroot/CFIDE when using the internal web server. The subdirectories in the CFIDE contain key ColdFusion functionality which may break if removed from the CFIDE directory. The following describes some of the subdirectories and the functionality each houses:

  • adminapi. The adminapi directory houses the ColdFusion MX 7 Administrator API code used for programmatic access to ColdFusion Administrator functionality. The ColdFusion Administrator itself implements some of the Admin API components. These components require the /CFIDE/adminapi directory path and the /CFIDE ColdFusion mapping in the administrator. The /CFIDE ColdFusion mapping is not configurable. Using the Admin API is discussed in chapter 11.

  • administrator. The administrator directory houses the ColdFusion administrator. This directory cannot be moved because it depends on the /CFIDE mapping and the Admin API code.

  • classes. The classes directory houses the java code (applet and JRE plugin) used for cfgrid, cfslider, and cftree java controls. This directory cannot be moved.

  • componentutils. The componentutils directory houses the ColdFusion Component Explorer (cfexplorer). The cfexplorer provides introspection of ColdFusion components. This directory cannot be moved.

  • scripts. The scripts directory houses the javascript, flash component, and xml used for <cfform>. This code is used for client-side validation, creating Flash Forms, and applying XML skins. This directory can be moved anywhere on the server and pointed to in the ColdFusion Administrator or the scriptsrc attribute of <cfform>.

  • wizards. The wizards directory houses components used by the ColdFusion MX 7 Login Wizard extension for Dreamweaver MX 2004. This directory cannot be moved.

The following are best practices for securing the CFIDE directory without limiting the functionality of its subdirectories:

  • Keep the directory structure intact. Do not remove any of the subdirectories from CFIDE.

  • Either configure ColdFusion to use the internal web server during installationto install CFIDE within the ColdFusion root directory (e.g. cf_root\wwwroot\CFIDE).

  • Or, move the entire CFIDE directory structure to a separate document root for your external web server, and create a virtual Web server or virtual directory to access it.

    TIP

    If you move the CFIDE directory modify the /CFIDE entry in the cf_root/lib/neo-runtime.xml file and restart ColdFusion. Point it to the absolute path where you are moving CFIDE. ColdFusion must be able to reach this path.

  • Apply OS and Web server permissions.

  • Protect access to the ColdFusion Administrator.

  • Leverage the Admin API to provide limited ColdFusion Administrator functionality to users.

  • Only allow access to the ColdFusion Administrator via the internal web server or a secure web server instance. Using the internal web server requires enabling it manually and restarting ColdFusion. Since using the internal web server is not recommended in Production, create a secure web server instance. Secure the instance with a protected IP address, and only turn the instance on for administrative purposes.

  • When creating sandboxes for applications, only provide read and execute access to the classes and scripts subdirectories.

TIP

If access to the ColdFusion Administrator is needed from multiple virtual sites, do not copy the CFIDE directory to each Web server instance. Instead, configure virtual directory mappings to the CFIDE directory for those server instances.

Limit Session Timeout Values

Session-scope variables are held in ColdFusion memory space until the Session Timeout is reached. The timeout is the period of inactivity between browser clicks. The Maximum Session Timeout value in the ColdFusion Administrator Memory Variables page defaults to two days. This is too long to let session variables remain in memory. Developers can enable application-specific session timeouts with the SessionTimeout variable in Application.cfc or the <cfapplication> attribute; however, the Administrator setting is the absolute maximum for the server. In other words, any coded SessionTimeout value greater than the Administrator setting is ignored.

Limit the Maximum Session Timeout to 3060 minutes. Remember that the timer restarts with every page request. It is a security hazard to let stale sessions linger on your serverthis gives hackers time to impersonate authenticated users. The Maximum Session Timeout is an administrator's only control over developers' Session scope variables.

Sessions can become invalid when enabling J2EE Session Management and if the Session Timeout value (in the Administrator or in developer's code) is greater than the J2EE Session Timeout. (This is Macromedia issue 51982 logged against CFMX 6.x, but it still exists in CFMX 7.) The workaround is to synchronize the Maximum Session Timeout and J2EE Session Timeout values. The J2EE Session Timeout is configurable in the Web deployment descriptor file, web.xml, found in cf_root/ WEB-INF/ (Server configuration) or cf_web_root/WEB-INF (Multiserver/J2EE configuration). Read Macromedia TechNote 19190 at http://www.macromedia.com/go/tn_19109.

The syntax for the workaround is:

<session-config> <session-timeout>66</session-timeout> </session-config>

CAUTION

The session settings affect the entire server. If J2EE Session Management is enabled in the ColdFusion Administrator, then it is enabled for every application on the server. This means ColdFusion uses the jsessionid value to uniquely identify browser sessions instead of CFID and CFTOKEN. ColdFusion will still send the CFID and CFTOKEN cookie values, but SESSION.SessionID becomes the jsessionid value. This may break some applications that rely on CFID and CFTOKEN as the session identifier. For more details consult the ColdFusion documentation or technote 18232, How to enable J2EE session management in ColdFusion at http://www.macromedia.com/go/tn_18232.

Removing Help Docs and Example Applications

For production systems, Macromedia recommends not installing the ColdFusion help documentation (cfdocs directory) and the example applications (gettingstarted directory). The help documentation and example applications are installed if you select the "Getting Started, Tutorials & Documentation" option on the Sub-component Installation screen of the ColdFusion MX 7 installer. Although the example applications display only for the local host (127.0.0.1), it is nevertheless recommended that they not be installed. If you have these folders installed on your production servers, remove them immediately.

Debugging IP Restrictions

Debugging output is invaluable for diagnosing errors during application development; however, it opens severe security holes on production systems by publicly displaying too much information. In development environments, ColdFusion administrators should restrict access to specific IP addresses. ColdFusion restricts debugging output to the local host IP by default, as shown in Figure 10.13. Administrators should completely disable the debugging service and robust exception information on production systems, as shown in Figure 10.14.

Figure 10.13. Enter IP addresses for which you want to receive debugging output. The loopback address is added by default.

Figure 10.14. Clear the check box next to Enable Debugging and press Submit Changes.

TIP

ColdFusion checks every IP address against the debugging IP list, which can slow pages down if the list becomes too big. Ideally, debugging access should be limited to just the local host or loopback address127.0.0.1.

Encrypt ColdFusion Templates

Previous versions of ColdFusion use the CFENCODE utility to encrypt the ColdFusion templates on the server. This utility, found in cf_root\bin, does not offer strong encryption, but it does make templates legible only to ColdFusion itself. To use CFENCODE, simply call it from the command line and pass a template name or path as an argument. If you specify a directory to encode, pass the /r parameter to recurse directory path.

The rub on CFENCODE is that it uses a weak encryption algorithm and is easily broken. Also, there is also a known crack for it available on the Internet, so developers are offered minimal protection.

CAUTION

You will not be able to read encoded templates, so save the original unencoded templates in a secured placepreferably on another server.

ColdFusion MX 7 introduces a stronger method of encrypting ColdFusion templates using the cfcompile command-line utility. The cfcompile utility is normally used to precompile ColdFusion templates into Java class files. The -deploy option instructs cfcompile to copy ColdFusion templates and convert their CFML into Java bytecode. Unlike templates encrypted with CFENCODE, a template encrypted by cfcompile can only be decoded to Java source code, and not back to the original CFML. This level of security enables sourceless deployment of developer code.

TIP

For more information on sourceless deployment, see the "ColdFusion Compiler" section of Chapter 6.

Handling Error Messages

Errors are a part of every application. ColdFusion errors give malicious hackers an abundance of information about your server and application, including filenames, server paths, and database structures. ColdFusion has a tag-based, structured exception-handling mechanism for managing run-time application errors<cftry>, <cfcatch>, <cferror>, <cfthrow>, and so on. However, this means depending on developers to properly code for errors. ColdFusion offers another solution: administrators can configure global templates for error handling, in the event that developers neglect to properly code for application errors. These templates are

  • The Missing Template Handler executes when ColdFusion fails to find a template.

  • The Site-wide Error Handler executes when ColdFusion encounters errors in a page request that are not handled by a coded Try-Catch block or <cferror>.

Configure both the Missing Template and Site-Wide Error handlers in the ColdFusion Administrator Settings page shown in Figure 10.15.

Figure 10.15. Specify paths to your Missing Template and Site-Wide Error handlers in the ColdFusion Administrator's Settings page.

Custom Tag Paths

Remove the default Custom tag path cf_root\CustomTags. This path is known to every experienced ColdFusion user and is accessible by all templates, including those restricted by sandboxes. The ColdFusion Sandbox file and directory permissions may not apply to all the tags in the custom tag paths. For example, a custom tag may exist in the global custom tags directory that may enable base template access to some unrestricted functionality. The best policy is to create custom tag directories within individual application sandboxes, and then require developers to use <cfmodule> and <cfimport> to access their custom tags.

TIP

ColdFusion looks for custom tags in the same directory as the calling template first, then in the global cf_root\CustomTags directory and its subdirectories, and finally in directories specified in the Custom Tags screen of the ColdFusion Administrator.

Filename Extension

The default filename extension for ColdFusion templates is .cfm. Consider changing this to another extension to help mask the fact that you have a ColdFusion site. Be careful to change the Web server file mappings to match your new ColdFusion extension. To change the extension mapping for ColdFusion, change the servlet mappings for .cfm in the cf_root\wwwroot\WEB-INF\web.xml file. The following entries change the ColdFusion extension from .cfm to .cfx:

<servlet-mapping> <servlet-name>CfmServlet</servlet-name> <url-pattern>*.cfx</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>CfmServlet</servlet-name> <url-pattern>*.cfx/*</url-pattern> </servlet-mapping>

CAUTION

If you change the filename extension of your ColdFusion templates, you may not be able to use the cfcompile utility for sourceless deployment. The version of cfcompile that ships with ColdFusion MX 7 is hard-coded to work on files with the default ColdFusion extensions: .cfm, .cfc, and .cfr. See the "ColdFusion Compiler" section of Chapter 6 for more information on cfcompile.

The best way to change the ColdFusion extension mappings for your Web server is to use the wsconfig command-line tool: cf_root\runtime\lib\wsconfig.jar. If your Web server is already configured for ColdFusion, you must first remove the connector. Use the sample code in Table 10.3 to remove the ColdFusion configuration for all your Web server instances.

TIP

Enter the commands in Tables 10.3 and 10.3 as single-line commands.

NOTE

You can only use the GUI wsconfig tool to reconfigure IIS. The GUI tool does not allow you to specify mappings for Apache or iPlanet.

TIP

You can remove all Web server connectors by specifying the -uninstall option without the -dir <config directory> or -site <site name> options.

To reconfigure your Web servers with the new ColdFusion extension, use the appropriate code in Table 10.4.

Table 10.4. WSCONFIG File Mapping Options

WEB SERVER

COMMAND

IIS

cf_root\runtime\bin\wsconfig.exe server coldfusion -ws IIS site sitename coldfusion map .cfx -v.

Apache

On Windows: cf_root\runtime\bin\wsconfig server coldfusion ws Apache -dir [path to httpd.conf] coldfusion -map .cfx -v. On Unix: ./cf_root/\runtime\bin\wsconfig server coldfusion ws Apache -dir [path to httpd.conf] coldfusion -map .cfx -v.

Sun ONE/iPlanet/Netscape

On Windows: cf_root\runtime\bin\wsconfig server coldfuion ws sunone|iplanet|nes -dir [path to conf directory] coldfusion -map .cfx v. On Unix: cf_root/runtime/bin/wsconfig server coldfusion ws sunone|iplanet|nes -dir [path to conf directory] coldfusion -map .cfx v.

Adding the Default Document

The default document is the file the Web server displays when a template name is missing from the URLfor example, www.mysite.com/. If this template is not configured, your Web server either returns a 403 Forbidden Access error or it lists the contents of the current directory. Consult your Web server documentation for information on configuring the default document.

Related

Категории