RSA Authentication Agent 5.3.4 for Web for Apache Web Server on Red Hat Linux 4.0 Readme

Document created by RSA Link Team Employee on Jan 6, 2017
Version 1Show Document
  • View in full screen mode

May 17, 2010

 

Introduction

This document lists what's new and changed in RSA Authentication Agent 5.3.4 for Web for Apache Web Server on Red Hat Linux 4.0 (referred to as "RSA Authentication Agent" in this document). Read this document before installing the software. This document contains the following sections:

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 on Red Hat Linux 4.0 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. The RSA Authentication Agent creates an 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:

  1. Copy the kit contents to a local directory.
  2. Log on to the computer with an account that has write permissions to the web server root directory.
  3. Change to directory you created when you downloaded the software and run the installation script. Type:

./install

  1. 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 on Red Hat Linux 4.0 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.

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 on Red Hat Linux 4.0 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 enhanced 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 DescriptionHyphen 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.

Security Contexts on Apache Web Server

If you configure security contexts on an Apache Web Server that hosts RSA Authentication Agent for Web, start the Apache Web Server as follows:

As root, copy the file /usr/sbin/apachectl to /usr/sbin/my_apachectl, and execute the start. Type:

my_apachectl start

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: 16432
Problem: If you log on to a protected web site, and attempt to access a different page of the web site after the initial cookie expires, you must reauthenticate. This happens because the refresh cookie generated by RSA Authentication Agent after the initial cookie expires is not detected by the Apache Web Server software.
Workaround: No workaround is available or required. This is how the Apache Web Server functions in this case; it is not a defect in RSA Authentication Agent.

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.


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.rsasecurity.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.

Attachments

    Outcomes