ATG Security Recommendations
against session spoofing
Document Information
- Title
- ATG Security Recommendations
- Subject
- against session spoofing
- Author(s)
- Güray Sen
- Comments
Document Version
v1@03/01/2006
Copyright
This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.
No Warranty
This document is provided 'as is' without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
The contents of this publication could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein; these changes will be incorporated in the new editions of the publication. Spindrift may make improvements and/or changes in the publication and/or product(s) described in the publication at any time without notice.
Limitation of Liability
In no event will Spindrift be liable for direct, indirect, special, incidental, economic, cover, or consequential damages arising out of the use of or inability to use this documentation even if advised of the possibility of such damages.
Contact
- Web
- www.spindriftgroup.com
Contents
1 Introduction
1.1 Document Goals
1.2 Related Documents
2 Background Information
2.1 About Session Tracking
2.2 Security Risks
3 Recommendations
3.1 Adjust Session Timeout
3.2 Turn On Verification of Remote Addresses
3.3 Educate Users
1 Introduction
1.1 Document Goals
This document provides recommendations to make ATG applications more secure against session spoofing.
1.2 Related Documents
The following documentation is related to this document:
2 Background Information
2.1 About Session Tracking
Session Tracking is a flexible, lightweight mechanism that enables stateful programming on the Web. It has a general implementation that serves as a basis for more sophisticated state models, such as persistent user profiles or multi-user sessions.
The Session Tracker servlet threads and coordinates server requests from individual users into a session. A session is a series of requests from the same user that occur during a time-period. This transaction model for sessions has many benefits over the single-hit model. It can maintain state and user identity across multiple page requests. It can also construct a complex overview of user behavior that goes beyond simply reporting user hits.
Dynamo matches requests to the appropriate session object with a session ID. The session ID is kept in the user's cookie where possible. If it is not possible to use a cookie, either because the user's browser doesn't support cookies or the user has chosen not to accept a cookie, Dynamo tracks the session by placing the session ID into the URL of the request and rewriting URLs in the requested page to include the session ID.
On the first request of a session, the session ID is always encoded into the URLs. This is because the session cookie doesn't exist on the client for the first request. The first response of a session sends the session cookie to the user client, along with a response page with links re-written to include the session ID in the URLs. If the user client accepts the session cookie, the subsequent requests and responses should not have the session ID encoded in the URLs.
2.2 Apache Connection Module
It is possible that someone else could enter the site and spoof a session if they had the right URL. That URL needs to contain the session ID for a session that has not been invalidated yet. This may happen, for example, when the computer is shared between users and the browsers history is used to re-issue requests before the session expires or when a link containing the session ID is send by email. The following section makes recommendations on how to prevent or minimize these security risks.
3 Recommendations
3.1 Adjust Session Timeout
The Session Manager, located at /atg/dynamo/servlet/sessiontracking/SessionManager, has a sessionInvalidationTime property that specifies how long a session can remain idle before Dynamo invalidates the session.
The default value for this property is 1800000 milliseconds, or 30 minutes. By reducing this value to, for example, 10 minutes, you reduce the time window in which other users can steal a user's session information by going through the browser history.
| Component | Property | Value |
| /atg/dynamo/servlet/sessiontracking/SessionManager | SessionInvalidationTime | 600000 |
3.2 Turn On Verification of Remote Addresses
If a user enters a Dynamo site and rejects cookies, the user's session ID becomes part of an encoded URL. It is possible that someone else could enter the site and use the session if they had the right URL. The verifyRemoteAddr property of the /atg/dynamo/servlet/sessiontracking/SessionManager component prevents this from occurring. When the verifyRemoteAddr property is turned on, Dynamo verifies that sessions have a consistent incoming RemoteAddr value, making it difficult for someone to steal another user's session. If the remote address changes, a new session is created for the user. The RemoteAddr is the IP address of the socket connecting to a Web server. For most users, this is consistent, but some proxy servers (such as America Online) have rotating IP addresses so this can change periodically.
The verifyRemoteAddr property can take one of three values:
- 0 - disabled (the default)
- 1 - verify remote address on all requests
- 2 - verify remote address only in URLs containing session IDs
Option 1 is the more secure, but may fail on server configurations where requests are redirected from a set of rotating proxy servers. Option 2 is less secure but effectively guards against accidental or intentional transfer of sessions via URLs shared by e-mail (and where the URL might contain a session ID).
| Component | Property | Value |
| /atg/dynamo/servlet/sessiontracking/SessionManager | verifyRemoteAddr | 1 |
Note that this setting does not prevent users from spoofing sessions when they are using the same IP address as the original session. For example, they are on the same computer or behind a proxy that issues all requests on behalf of the computers on the network.
For more information on Session Manager properties and how Dynamo handles cookies, see Session Manager Configuration in the Configuring Dynamo chapter of the Dynamo 5 Deployment Guide [3].
3.3 Educate Users
Session spoofing by, for example, going through a browsers history and re-issuing requests is not possible if the user has logged out of the application manually before allowing another user on his/her computer. Users need to be made aware of improved security by manually logging out by placing text on the pages, explaining the users why they need to log out when they are done with the application.