What security considerations should we ponder around URL rewriting issue?

Products

• CA Single Sign On Secure Proxy Server (SiteMinder)
• CA Single Sign On SOA Security Manager (SiteMinder)
• CA Single Sign-On

Issue/Introduction

Login, Authentication and SSO Session (the basics):

SMSESSION is a Transient Cookie: A SiteMinder environment with (one or more) Policy Servers and 'traditional' Web Agents tracks a users 'web' session using an SMSESSION cookie. By default this is a transient (or session) HTTP cookie set in the users browser, hence it will be removed when the user's browser session is closed, or when another web server expires or overwrites the cookie in the same domain.

SMSESSION contains encrypted data from both the Web Agent and Policy Server: When a user logs in the Web Agent asks the Policy Server to authenticate the user (over the RSA RC4 encrypted connection between the agent and Policy Server). If the user can be authenticated, the Policy Server generates a unique session ID, this ID is combined with the user's identity and other tracking data and is encrypted using the 'Session Ticket Key' to create a Session Ticket. If the SiteMinder session server is enabled then the session ID is written in the session store. It is the Session Ticket that is returned to the Web Agent with the authentication success message. The Web Agent then combines the encrypted Session Ticket with its own tracking data and encrypts the result using the 'Web Agent Key' to produce the content for the SMSESSION cookie. This cookie is returned to the user's browser in the HTTP(s) response. CA always recommends that all authentication and access to secured content is provided over SSL (HTTPS). Once the user has an SMSESSION in her browser, the cookie will be provided in the subsequent HTTP(s) request to any web server in the matching cookie domain. If the Web Agent is configured to 'UseSecureCookie' then the SMSESSION is flagged with the cookie secure parameter - this is an instruction to the web client (browser) to only send the cookie over SSL connections (obviously it is up to the client to enforce this).

SMSESSION provides SSO: When an SMSESSION cookie is presented to a Web Agent secured server, the agent can decrypt the cookie if it shares the same Web Agent Key as the Web Agent which encrypted the cookie. After its own validation the agent will present the encrypted Session Ticket to a Policy Server. The Policy Server can decrypt the Session Ticket IFF it shares the same Session Ticket Key as the Policy Server which encrypted the Session Ticket, it can also validate the Session Ticket IFF it applies the same Policies to the user repository. It is important to note the Web Agent never has access to the Session Ticket Key on the Policy Server. The keys are shared using the Key Store and maybe rotated at configured intervals. The SSO solution provides flexibility to deploy multiple protected Web Servers and Policy Servers; providing high performance, redundancy, availability and scalability across multiple sites and geographies. This can be provided with minimal data replication - i.e. shared keys.

Man in the Middle (stealing a cookie):

HTTP is a stateless protocol; HTTP session cookies allow the user to maintain a security or application session across web based applications. There are other session tracking solutions, including SSL ID tracking, URL rewriting (and query strings). However, cookies are the least bad solution. SSL ID's are renegotiated by the client during a single session (by the client), URL rewriting or other URL schemes are weak as the URL is exposed in many more scenarios than a cookie would be exposed, and unique session URLs impact on caching solutions. With an HTTP session cookie solution there are a number of scenarios where an attacker may steal the cookie; any security solution is only as strong as its weakest link:

1. Between the browser (client) and web server: If the HTTP request containing a cookie is transmitted over HTTP then the cookie may be taken by any device with promiscuous access to the wire (or Wi-Fi) connection. CA always recommends the use of SSL (HTTPs) communication for all secure traffic; additionally measures should be in place to prevent the cookie from being unwittingly sent over HTTP (i.e. use of the secure flag and phishing prevention). With the correct implementation SSL will prevent an attacker from stealing a cookie from the connection between the browser and backend. By keeping up to date with web server and browser security patches, any risk of an exposed weakness in the SSL implementation can be mitigated.
   
   
2. Between SSL termination and the web infrastructure: HTTP SSL is often terminated on a hardware acceleration device which sits in the DMZ in front of other web server infrastructure. As such, if an attacker can snoop the network in this segment or gain access directly to the device or server, he may be able to steal unencrypted cookies. If an attacker has this level of access, it is clear that there are bigger issues than simply stealing a single users session cookie, the attacker can capture all user HTTP traffic, potentially including authentication credentials presented over the SSL connection. This type of attack can be mitigated by definition and enforcement of corporate security policies (outside the scope of this note; industry standards such as ISO 17799 and CobIT cover such policy management).
   
   
3. On the Web Server: If the attacker has admin access to the DMZ web server, he may install a new or replacement plug-in (NSAPI/ISAPI/Apache Module etc.) to capture all traffic in the web server, and use this to capture cookies. Or he may configure the server to write cookies to a log, and then capture the log data. Again this is a bigger problem than capturing a single cookie; the attacker could also capture credentials.
   
   
4. On the Client: In most cases this is the weakest component. In a corporate environment client desktop/laptop configuration can be controlled and access can be physically managed. In a consumer environment, the client may be a PC or other device in a user's home, or a public space. If an attacker can install malicious code on the client PC he can log/record all HTTP traffic and capture cookies, potentially he could remotely administer or collect cookies from an infected machine. Or more simply the attacker may be able to gain access to the client machine and copy the cookie whilst the user has an authenticated session and is distracted or on a coffee break.

In the examples above, where the attacker has access to be able to programmatically capture the cookie in plain format, he would most likely also have access to capture entered credentials in plain format - which is arguably more dangerous than the cookie itself. If a cookie is captured there are safeguards to prevent it from being 'replayed'.

Logout and Session Timeout:

If a cookie is stolen it must be reused within the Max Session Time and Max Idle Time configured on the SiteMinder protected realm. So by configuring a short Idle Timeout, the window of opportunity for a reply can be reduced. And by configuring a short Max Session Time the period for which the session can be reused before the user must re-authenticate is limited.

If Transient IP Checking is enabled on the SiteMinder Web Agent configuration object, then any replay of the cookie must originate from the same IP address as the original authentication (the original IP address is contained in the encrypted content of the session cookie). Due to HTTP proxies, firewalls and NAT it is likely that requests which are routed over the internet, from say a machine on a corporate network, will look to originate from the same IP address, so the transient IP check does not prevent all cookie replay attacks.

If the user logs out from his authenticated session then this does not automatically prevent a stolen session cookie from being re-used. The default behavior for logout is to invalidate the browsers copy of the session cookie by overwriting the content, additionally all Policy Server and Web Agent memory caches pertaining to the session are flushed, the session flush may take up to twice the time of the Web Agent management interval or Policy Server admin interval (default is one minute) to propagate to all Web Agents.

To prevent any access using a stolen session cookie after the user has logged out. The SiteMinder Session Server must be enabled. This database tracks the sessions (by session ID) generated by each Policy Server. When a logout occurs the session is removed from the Session Server, so can no longer be validated.

The Session Server database must be accessible by each Policy Server, and is access for authentication, logout and at any point where the Policy Server(s) must validate the users session. As such there is additional overhead when using the Session Server. To limit this overhead it is possible to enable the Session Server on a per-Realm.

Let?s consider the 4 position the attack could come from, as described in the previous note:

1. Between the browser (client) and web server
   
   
2. Between SSL termination and the web infrastructure
   
   
3. On the Web Server
   
   
4. On the Client

In cases 2 and 3, there is nothing we can do on the SiteMinder side. On the other hand, if an attacker was to get access there, he would probably focus on getting different information than session cookies.

In case 1, CA always recommends the use of SSL (HTTPs) communication for all secure traffic.

Additionally measures should be in place to prevent the cookie from being unwittingly sent over HTTP:

• Use relative redirect by configuring TargetAsRelativeURI parameter to YES.
  You can instruct the Web Agent to use a relative URI instead of a fully qualified URL when directing requests to a credential collector and target resource. The Web Agent will redirect to credential collectors using a relative URI and will redirect back to the TARGET using a relative URI. The server name specified in the TARGET parameter is ignored. This restricts the redirects to the current server thus preventing phishing attacks.
  
  
• Encrypt the redirect URL by setting SecureURLs parameter to YES.
  Setting the SecureURLs configuration parameter to YES enables the Web Agent to encrypt all SiteMinder query parameters in the redirect URL. Web Agent will provide secure URLs by encrypting the information sent to the credential collector. This prevents modification of the TARGET parameter.
  
  
• Restrict Redirect Domain
  The Web Agent Forms Credential Collector (FCC) in FCC compatibility mode (fcccompatmode=YES) will only redirect to a TARGET server name in the same domain as the resolved cookie domain of the Web Agent hosting the FCC, thus preventing phishing attacks.
  
  
• If you need other cookies than smsession to be secure and encrypted, use UseSecureCookies parameters.

In case 4, we can imagine an attacker getting physical access to a PC. In that case, I imagine he would simply copy the session cookie and paste it on his own machine, to be able to access the session. The best prevention here is to educate and remind employees that they should never leave their PC unattended without locking it first.

Anyway, if you think this is a high risk in your environment, please read the section "Logout and Session Timeout", where it is explained some principles such as Transient IP, Max Session Time and Max Idle Time, Session Server. Although those will not prevent the attacker to steal the cookie, it does mitigate the risk.

As you explained me, your company went under a security audit which recommends to put in place additional protection against phishing. At the moment, you are using HTTPS and standard SiteMinder security recommendations.

We have discussed the 3 main parameters relative to phishing that you could use. However, along our conversation, it appeared that there was cross incompatibility between those. Please find below a summary of dependencies and incompatibilities for those 3 parameters.

• TargetasRelativeUri:
  
  This setting applies to all credential collectors except the cookie credential collector (ccc). For ccc, you would use the parameter validtargetdomain to avoid phishing attack.
  
  
• SecureUrls:
  
  The web agent only encrypts query parameters between SiteMinder components. The data sent for redirects to non-SiteMinder applications is not encrypted.
  
  For example:
  In the url
  http://servername/sites/sitecollection/_layouts/formserver.aspx?xsnlocation=~sitecollection/formlibrary/forms/template.xsn&savelocation=~sitecollection/formlibrary&source=~sitecollection/formlibrary the part of the url after the question mark will be encrypted so the url may look like http://servername/sites/sitecollection/_layouts/formserver.aspx?dsjmdjkilouy76nkl98tt (this is not a real example).
  
  For example queries could be things like smauth, onauthaccept, smauthaz.
  
  The following SiteMinder credential collectors and applications support the secureurls functionality:
  
  
  • HTML forms authentication
    
    
  • Cert and forms authentication
    
    
  • SSL authentication
    
    
  • Cert or forms authentication
    
    
  • NTLM authentication
    
    
  • Ace authentication
    
    
  • Safeword authentication
    
    
  • User self registration
    
    
  • Multi-domain single sign-on with cookie provider
    
    
  • FCC-based password services (not cgi- or jsp-based)
    
    The advantage of this parameter if someone intercepts the url, he will not be able to redirect it because if anything is changed in the url, the web agent won?t accept it.
    
    The secureurls feature is not supported when any of the following parameters are enabled: fcccompatmode, legacyencoding.
    
    
• FCCCompatMode:
  
  The web agent forms credential collector (FCC) in FCC compatibility mode (fcccompatmode=yes) will only redirect to a target server name in the same domain as the resolved cookie domain of the web agent hosting the FCC, thus preventing phishing attacks.
  
  
• StoreSessioninServer:
  
  Specifies whether single-use session cookies are used. When the value of the StoreSessioninServer parameter is yes, a single-use session cookie is created and stored on the session server. Cookie providers and web agents access the cookie from the session server. Cookie providers and web agents replace the session cookie in a url with a GUID that corresponds to the single-use session cookie stored on the session server. When the value of the StoreSessioninServer is NO, the session cookie is passed directly in the URL. Default is NO.

Environment

Release:
Component: SMPLC