The embedded service provider of the Access Gateway and the Access Gateway both use session cookies in their communication with the browser. The following sections explain how to protect these cookies from being intercepted by hackers
For more information about making cookies secure, see the following documents:
An attacker can spoof a non-secure browser into sending a JSESSION cookie that contains a valid user session. This might happen because the Access Gateway communicates with its embedded service provider on port 8080, which is a non-secure connection. Because the embedded service provider does not know whether the Access Gateway is using SSL to communicate with the browsers, the embedded service provider does not mark the JSESSION cookie as secure when it creates the cookie. The Access Gateway receives the Set-Cookie header from the embedded service provider and passes it back to the browser, which means that there is a non-secure, clear-text cookie in the browser. If an attacker spoofs the domain of the Access Gateway, the browser sends the non-secure JSESSION cookie over a non-secure channel where the cookie might be sniffed.
To stop this from happening, you must first configure Access Gateway to use SSL. See Section 14.3, Configuring SSL Communication with the Browsers and the Identity Server. After you have SSL configured, you need to configure Tomcat to secure the cookie:
On the Linux Access Gateway machine, log in as root.
Change to the /var/opt/novell/tomcat4/conf directory.
In a text editor, open the server.xml file.
Search for the connector on port 8080.
Add the following parameter to this connector:
These lines should look similar to the following:
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true" secure="true" />
Save the server.xml file.
Restart Tomcat by entering the following command:
The proxy session cookies store authentication information and other information in temporary memory that is transferred between the browser and the proxy. These cookies are deleted when the browser is closed. However if these cookies are sent through a non-secure channel, there is a threat of hackers intercepting the cookies and impersonating a user on Web sites. To stop this from happening, you can use the following touch files:
Prevent the browser from sending cookies on a non-HTTPS channel: You can configure the Linux Access Gateway to set its authentication cookie with the secure keyword in order to prevent the browser from sending this cookie on a non-HTTPS channel. Use the following touch file to set the authentication cookie with a secure keyword:
NOTE:This works only for HTTPS services. When this setting is enabled, you cannot configure the Access Gateway to have an HTTP service that requires authentication, or create a policy that depends on the authentication cookie.
Set an authentication cookie with a secure keyword for HTTP: You can use the following touch file to force the HTTP services to have the authentication cookie set with the keyword secure.
This touch file is used to secure the cookie when the Linux Access Gateway is placed behind an SSL accelerator, such as the Cisco SSL accelerator, and the Linux Access Gateway is configured to communicate by using only HTTP.
Prevent cross-site scripting vulnerabilities: Cross-site scripting vulnerabilities in Web browsers allow malicious sites to grab cookies from a vulnerable site. The goal of such attacks might be to perform session fixation or to impersonate the valid user. You can now configure the Linux Access Gateway to set its authentication cookie with the HttpOnly keyword, to prevent scripts from accessing the cookie. To enable this, use the following touch file: