May 17, 2010
Introduction
This document lists what's new and changed in RSA Authentication Agent 5.3.4 for Web for Apache (2.0 or earlier) Web Server (referred to as "RSA Authentication Agent" in this document). Read this document before installing the product. This document contains the following sections:
- What's New in This Release
- What's Fixed in This Release
- Installation
- Enabling Enhanced Cookie Protection
- Technical Notes
- Obtaining the Version Number of RSA Authentication Agent Software
- Support for Worker Multi-Processing Module
- Multidomain Access
- Browser Caching
- Known Issues
- Getting Support and Service
This Readme may be updated. The most current version can be found on RSA Link at https://community.rsa.com/. Or, you can print this Readme.
What's New in This Release
Version 5.3.4 of RSA Authentication Agent provides enhanced RSA SecurID cookie protection (issue 125836) and fixes other security issues. See What's Fixed in This Release for a list of all fixed security issues.
Enhanced RSA SecurID cookie protection includes the following changes:
- The Common Gateway Interface (CGI) command has been modified so that it permanently invalidates the RSA SecurID cookie after a user logs off. This change prevents an unauthorized user from using a copied cookie to access protected web pages.
- A new HTML template (RSASecurID_Logoff_UNIX_Web.htm) provides a web developer with an example of how to link to the CGI command through a Log Off link. The new template also contains code that shows how to invoke the CGI command even if the user closes the browser without clicking the Log Off link. During the installation process, RSA Authentication Agent automatically installs the new HTML template file in the install_dir/Templates directory.
For more information on how to configure and use the enhanced cookie protection features, see Enabling Enhanced Cookie Protection.
What's Fixed in This Release
Version 5.3.4 of RSA Authentication Agent resolves these issues.
An unauthorized user could gain access to protected web pages by reusing a copied cookie after the authorized user logs off.
Tracking number: 125836
To prevent this unauthorized access, enhanced cookie protection features are provided in this release of RSA Authentication Agent. For more information, see Enabling Enhanced Cookie Protection.
For more information on using the CGI command to invalidate cookies, see "Using the Log Off URL to Invalidate Web Access Authentication Cookies" in the RSA Authentication Agent 5.3 for Web for Apache Web Server Installation and Configuration Guide.For more information on using the RSA SecurID Logoff UNIX Web template, see Enabling Enhanced Cookie Protection.
The HTTPOnly flag is not set automatically on the rsa-local cookie.
Tracking number: AAgent-2024
When using RSA Authentication Agent, the rsa-local cookie is not set to HTTPOnly. RSA Authentication Agent creates a rsa-local cookie that contains user credentials. If the rsa-local cookie is not set to HTTPOnly, cross-site scripting (XSS) attacks can occur. To prevent cross-site scripting (XSS) attacks, the rsa-local cookie is now set to HTTPOnly.
A SmartAttack analyzes forms within the application to determine which forms allow content caching.
Tracking number: AAgent-2286
When a form allows content to be cached, values previously entered into the form are stored in the client's web browser.
Cross-frame scripting can be used to capture RSA Authentication Agent content in any web site that uses <frame> and <iframe>.
Tracking number: AAgent-2287
To protect this content, new frame-busting code has been added to RSA Authentication Agent HTML templates. Whenever the frame-busting code executes, RSA Authentication Agent is immune to cross-frame scripting, which enhances security. The frame-busting code provides additional security, but a new environment variable allows the administrator the option of using it or not, depending on the needs of the particular site. For example, a site might have a special environment (such as in a Web application) where the administrator wants the SecurID log on prompting page to show in the custom frame.
A new environment variable named RSA_NO_FRAME_BUSTING controls the behavior of the frame-busting code. By default, the frame-busting code executes when the RSA_NO_FRAME_BUSTING variable does not exist. If the administrator does not want the frame-busting code to execute, he or she must set the environment variable, RSA_NO_FRAME_BUSTING, to 1. If the administrator later wants to re-enable the frame-busting code, he or she can simply remove the environment variable or change it to a value other than 1.
Password fields that do not have auto-complete turned off allow access to previous password entries on a page. This enables attackers to discover and abuse passwords.
Tracking number: AAgent-2288
Password fields now have auto-complete set by default.
Installation
You can install version 5.3.4 of RSA Authentication Agent as a full installation or as a patch to a previous version. For example, if your computer does not have RSA Authentication Agent 5.3 or earlier installed, the full product installs on the computer. If you do have RSA Authentication Agent 5.3 or earlier installed, this patch upgrades the product and saves your current settings.
Important: Before you install RSA Authentication Agent, perform the tasks described in the Workarounds for the following Known Issues: AAGENT-2283 and AAGENT-2284.
To install RSA Authentication Agent as a full installation or as a patch:
- Copy the kit contents to a local directory.
- Log on to the computer with an account that has write permissions to the web server root directory.
- Change to the directory you created when you downloaded the software, and run the installation script. Type:
./install- Follow the prompts to install the software.
For details on testing or configuring RSA Authentication Agent, see the RSA Authentication Agent 5.3 for Web for Apache Web Server Installation and Configuration Guide.
Important: The installation process installs the new RSA Cookie Server and starts it. This server provides the protection against using copied cookies. Without the RSA Cookie Server (for example, if it should stop), you see prompts to authenticate each time you access pages within the application. If you see authentication prompts for each URL you access, you must restart the web server.
Enabling Enhanced Cookie Protection
To use the enhanced cookie protection, a web developer can choose to do one or both of the following to permanently invalidate the RSA SecurID cookie and end the session on the web page:
- Invoke the CGI command from the Log Off link in the web page protected by SecurID. For example, you could specify http://www.server.domain.com/webauthentication?logoff?referrer=/sample.html, where server.domain.com is the fully qualified name of the web server. When the user clicks the Log Off link, it permanently invalidates the cookie and ends the session for that page. For more information, see "Using the Log Off URL to Invalidate Web Access Authentication Cookies" in the RSA Authentication Agent 5.3 for Web for Apache Web Server Installation and Configuration Guide.
- Copy the Javascript header from the RSASecurID_Logoff_UNIX_Web.htm template and paste it into the protected pages of the web site. With this Javascript header in place, the action of closing the browser permanently invalidates the RSA SecurID cookie. However, you may need to modify the Javascript according to the requirements of the web page.
To turn off the cookie protection, you can set the following environment variable:
RSA_NO_LOGOFF_COOKIE_CHECKING = 1
Enabling Enhanced Cookie Protection in Multiserver and Multidomain Environments
To ensure that cookie protection works across multiple web servers in a single or multidomain environment, you must perform additional domain configuration for all servers in all domains. For example, if you have two domains, domain A and domain B (Figure 1), and two web servers in each domain, you must configure each web server in both domain A and B.
Figure 1
For each server that you configure, list all the servers in all domains in your environment, using the hyphen symbol as explained in the following table.
| Server Description | Hyphen Symbol Usage in URL |
|---|---|
| Server representing a domain other than the domain of the server being configured. This one server is the domain server for the other domain. | No hyphen before the URL. http://www.domainserver.com |
| Servers that do not represent a different domain than the server being configured. These can be servers in the same domain as the server being configured, as well as servers in different domains that do not serve as the domain server. Only one server from a different domain serves as the domain server, and therefore it is the only server from the different domain not to have the hyphen in the URL. | Precede the URL with a hyphen. -http://www.allotherservers.com |
The following are sample configurations for each server in domain A and domain B.
To configure server S1A, list the following URLs:
-http://www.S2A.com
http://www.S1B.com (domain server for domain B)
-http://www.S2B.com
To configure server S2A, list the following URLs:
-http://www.S1A.com
http://www.S1B.com (domain server for domain B)
-http://www.S2B.com
To configure server S1B, list the following URLs:
-http://www.S2B.com
http://www.S1A.com (domain server for domain A)
-http://www.S2A.com
To configure server S2B, list the following URLs:
-http://www.S1B.com
http://www.S1A.com (domain server for domain A)
-http://www.S2A.com
Technical Notes
This section provides additional technical information about the product.
Obtaining the Version Number of RSA Authentication Agent Software
To obtain the version number of RSA Authentication Agent software:
1. Change directories to the RSA Authentication Agent directory, for example: /usr/local/apache/rsawebagent.
2. Type:
strings mod_rsawa_apache.so | grep "Agent"
Support for Worker Multi-Processing Module
RSA Authentication Agent 5.3 for Web for Apache Web Server supports the Worker Multi-Processing Module (MPM). Previous releases supported Prefork MPM. Support for Worker MPM is configured automatically during RSA Authentication Agent installation.
Multidomain Access
If you are setting up multidomain authentication, you must use the same WebID URL across all web servers. When using IIS web servers and Apache web servers, change the WebID URL on the Apache servers to /WebID/IISWebAgentIF.dll. For more information, see the RSA Authentication Agent 5.3 for Web for Apache Web Server Installation and Configuration Guide.
Browser Caching
For security purposes, instruct end users to disable caching in their browsers.
Known Issues
This section describes issues that remain unresolved in this release. Wherever a workaround or fix is available, it has been noted or referenced in detail. For many of the workarounds in this section, you must have administrative privileges. If you do not have the required privileges, contact your administrator.
Tracking Number: AAGENT-2283
Problem: When you try to install RSA Authentication Agent on the UNIX operating system, it fails because the installation script does not have the required execute permission.
Workaround: Before installing RSA Authentication Agent, add the execute permission to the installation script with the command chmod +X install.
Tracking Number: AAGENT-2284
Problem: After installation of RSA Authentication Agent on a UNIX platform, the first access of a web page protected by RSA SecurID can fail after the user enters a valid user name and passcode. The failure on first access of a web page protected by RSA SecurID can occur due to insufficient privileges for RSA Authentication Agent to write to the VAR_ACE directory.
Workaround: Before installing RSA Authentication Agent, add read and write permissions to the VAR_ACE directory, /var/ace, with the command chmod +rw /var/ace.
Platform: Apache
Problem: The Content Type HTTP header in web pages generated by RSA Authentication Agent was set incorrectly.
Workaround: RSA Authentication Agent now uses the Apache API ap_made_content_type() to get content type information. However, the web site administrator must use the AddDefaultCharset directive value in the httpd.conf file to specify the character type for the web page. Do one of the following:
If you are using html, and you want to specify the character set(s) in the .html code for the web page, set the AddDefaultCharset value in the httpd.conf file to off.
If you are using html, and you want to enable the Apache internal default charset of iso-8859-1, set the AddDefaultCharset value in the httpd.conf file to on.
Specify an alternate character set by setting the AddDefaultCharset directive value to be something other than the default character set.
Getting Support and Service
RSA Link: https://community.rsa.com/
Customer Support Information: www.rsa.com/support
RSA Secured Partner Solutions Directory: http://www.rsasecured.com/
Copyright © 2010 EMC Corporation. All Rights Reserved.
Trademarks
RSA and the RSA logo are registered trademarks of RSA Security Inc. in the United States and/or other countries. For the most up-to-date listing of RSA trademarks, see www.rsa.com/legal/trademarks_list.pdf. EMC is a registered trademark of EMC Corporation. All other goods and/or services mentioned are trademarks of their respective companies.
On this page
