Symantec Access Management

Expand all | Collapse all

SiteMinder Cookies, their Usage, Contents and Security

  • 1.  SiteMinder Cookies, their Usage, Contents and Security

    Broadcom Employee
    Posted Nov 28, 2012 10:37 AM

    Tuesday Tip by Vijay Masurkar, Principal Support Engineer, for 11-27-12

    A question such as this has often come up: For Each SiteMinder cookie type, please provide information as to when they are used, their content, ways to secure them: SMSESSION, SMIDENTITY, SMDATA, SMTRYNO, SMCHALLENGE, SMONDENIEDREDIR, SMUSRMSG.

    SMSESSION: Is set by Web Agent upon authentication. This cookie represents a user’s session and contains:

    User’s ID (User name and user DN)
    ClientIP address
    ID of the directory or database from which the user was authenticated
    SMSESSIONSPEC
    Unique Session ID (a hash of the GUID of the logged in user)
    Creation time
    Last Access Time, etc.

    SMIDENTITY: When an anonymous user accesses resources (with user tracking enabled), that user is assigned an SMIDENTITY (anonymous) cookie. When the user moves to another domain, the user is challenged, and if logs in successfully, then is assigned an SMSESSION (logged in) cookie. As this user accesses protected and "anonymous" resources (i.e. resources in a realm that do not require a user to present credentials), the user may enter a domain that contains both cookies for a user. For resources protected by Web Agents starting at 5.x QMR 3 , the Web Agent uses the SMSESSION cookie to identify the user, not the SMIDENTITY cookie. If the user goes from a thoroughly upgraded domain to a domain where older Agents use the SMIDENTITY cookie to identify the user, the cookie used depends on the version of the Web Agent handling the request. For affiliates, the SMIDENTITY cookie is used to inform the affiliate who is trying to access the affiliate site.

    SMDATA: Is set by Web Agent to store encrypted user information. It is used when a user selects the save credentials option. With this option selected in your login page, you can return to the site after your session has ended and automatically login using the contents of the SMDATA cookie.

    SMTRYNO: Contains number of failed login attempts. Note that when using the DynamicRetry pair of .fcc files, you cannot count user login attempts based on the SMTRYNO cookie.

    SMCHALLENGE: Is set by Web Agent when using Basic authentication. The value of this cookie is initially set to YES, which causes the user to be prompted for credentials. The Web browser then sends this cookie back with the credentials entered in the authorization header.

    SMONDENIEDREDIR: Is set by Web Agent when using Basic authentication with a redirect upon failed authentication. If both authorization header and the SMONDENIEDREDIR cookie exist, SiteMinder issues a 401 error message. This ensures that users are locked out if they click a Back button.

    SMUSRMSG: Is supported for the custom authentication scheme only when FCCCompatMode set to yes. Beginning with v5 QMR3, the Web Agent has the ability to convert the text from an SM_AGENTAPI_ATTR_USERMSG response to a SMUSRMSG cookie when performing a forms challenge. To ensure the SMUSRMSG cookie is removed after the challenge is complete, the FCC consumes the cookie (deletes it from the browser) after a successful POST request,

    Further, note that these cookie names can change. SSOZoneName ACO parameter specifies the (case-sensitive) name of the single sign-on security zone a Web Agent supports. The value of this parameter is prepended to the name of the cookie a Web Agent creates. This helps you associate cookies with their respective cookie domains. So, when this parameter is not empty, SiteMinder generates cookies using the following convention: <Zonename><Cookiename>

    Default: Empty (uses SM as a zone name, which gives the cookies the following default names):

    SMSESSION, SMIDENTITY, SMDATA, SMTRYNO, SMCHALLENGE, SMONDENIEDREDIR

    Example: Setting the value to Z1 creates the following cookies:

    Z1SESSION , Z1IDENTITY, Z1DATA, Z1TRYNO, Z1CHALLENGE, Z1ONDENIEDREDIR


    Securing Cookies

    To help protect against cross-site scripting attacks, you can make the Web Agent set the HTTP-Only attribute for any cookies it creates using the following ACO parameter (introduced in 6QMR5 HF06 ): UseHTTPOnlyCookies. Also, you can specify that session cookies are only sent between a protected web server and the requesting browser over secure (HTTPS) connections using the following parameter: UseSecureCookies. See further security best practice details for Web Agents and Cookies in the Agent Configuration Guides for the agent versions in your infrastructure.



  • 2.  RE: SiteMinder Cookies, How They Are Used, Contents and Security

     
    Posted Nov 28, 2012 04:54 PM
    Thanks for the tip Vijay! :grin:


  • 3.  RE: SiteMinder Cookies, How They Are Used, Contents and Security

    Posted Nov 28, 2012 05:05 PM
    Does CA have a tool that can decode a SMSESSION cookie to get the information out of it (client ip, username etc) ?
    Probably not that useful as its in the audit log but was wondering.


  • 4.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Nov 29, 2012 11:49 AM

    masvi10 wrote:

    Tuesday Tip by Vijay Masurkar, Principal Support Engineer, for 11-27-12

    To help protect against cross-site scripting attacks, you can make the Web Agent set the HTTP-Only attribute for any cookies it creates using the following ACO parameter (introduced in 6QMR5 HF06 ): UseHTTPOnlyCookies.
    Be careful with this setting -- it does it exactly what it says on the tin. Once this flag is set you will not be able to pass any of the SiteMinder cookies outside of simple browser HTTP requests. This means if you rely on Javascript, applets, etc. for custom authentication or integration with COTS products it will break. Oddly, we've particularly noticed this problem integrating with non-CA Identity Management products.

    As with any change, test carefully before deploying. :)


  • 5.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Nov 30, 2012 04:27 PM
    SiteMinder Session security really revolves around 2 parts,
    1) How can i prevent the cookie from getting stolen
    2) If the cookie is stolen, how can i limit the damage

    There are several other SiteMinder Settings that can be used to prevent the cookie from getting stolen.

    Name of cookie
    SSOZoneName ACO Setting
    Default is “SM”
    SSOTrustedZone is used to define which an agent trusts, The Zone named in SSOZoneName is always trusted by default

    Transient or persistent
    PersistentCookies (SMSESSION cookie) ACO Setting - Default is No = Transient
    TransientIDCookies (SMIdentityCookie) ACO Setting – Default is No = Persistent
    NOTE: SharePoint agent always uses a separate persistent cookie (SPSESSION)
    Path

    CookiePath ACO Setting is for all of the other SiteMinder Cookies
    MasterCookiePath ACO Setting controls the path for cookies created using a cookie Provider
    Default path for CookiePath and MasterCookiePath is /
    CookiePathScope ACO Setting to auto-detect the depth of the cookie path

    Domain
    CookieDomain ACO Setting
    If CookieDomain is not set The Agent automatically detects the domain and uses the CookieDomainScope setting
    If CookieDomainScope is undefined it will default to 2
    Use CookieDomain to limit which sites the browser will send the cookie
    The browser will send the SiteMinder Cookie to all websites access in the domain – regardless if they are SM protected or not

    SSL
    UseSecureCookies ACO Setting
    Default is No
    Prevents the browser from sending the cookie over clear-text, although it will be sent to SSL enabled sites that are not using SiteMinder hat match the CookieDomain

    HTTP Only
    UseHttpOnlyCookies ACO Setting
    Default is No


  • 6.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Nov 30, 2012 04:30 PM
    If the cookie is stolen there are some things that can be done to limit risk:

    IP Checking
    Verify that the cookie came from the same Browser / IP address to where it was originally sent
    Catches someone stealing and then trying to replay the cookie from a different IP address
    Forces IP Address spoofing on top of Cookie Capturing
    Has a Bad Reputation since web server doesn’t always see the actual IP address of the end user due to NAT, firewalls, proxies, etc.

    Separate settings for transient or persistent cookies
    TransientIPCheck ACO Setting Default is NO
    PersistentIPCheck ACO Setting Default is Yes

    Doing IP Checking with NAT and Proxy devices
    CustomIPHeader ACO Setting Default Is undefined
    Gets the public IP address of a user from a header variable
    If the Proxy or the NAT device can insert this header SM can read it

    Some users come through a NAT or Proxy and others don’t
    ProxyDefinition ACO Setting Default is undefined
    Will only look for the CustomIPHeader header variable if the request comes from a specific IP Address


    Limitation : CustomIPHeader and ProxyDefinition are not tied together. For example header1 cannot be used only for proxy1 and header2 only for proxy2

    Session timeout and idle timeout are configurable
    Keep Timeouts as small as possible – reduces window for replay

    Realm / Application Based Timeouts
    The realm you login into sets your session and idel timeouts for the lifetime of the session regardless of the timeouts of the realm currently being visited

    Timeouts using responses
    Timeouts gets enforced based on the realm you are currently accessing
    EnforceRealmTimeouts ACO Setting
    Default is NO
    WebAgent-OnAuthAccept-Session-Max-Timeout response
    WebAgent-OnAuthAccept-Session-Idle-Timeout response
    Response redirects can be defined by user policies so not all users have the same timeouts


  • 7.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Nov 30, 2012 04:32 PM
    Also the Cookie Provider is a place many people are concered about for cookie security

    Cookie Providers are particularly vulnerable since they place the session onto the URL QueryString
    Any agent can act as a cookie provider
    Places Session information on the query string making it easier to capture and then replay
    Can “bounce” a session off of a cookie provider so it can be used in another domain

    Restrict a Cookie Provider to specific target domains
    ValidTargetDomain ACO Setting default is undefined
    Specifies which domains the cookie provider will forward sessions to

    Changing Cookie Provider Extensions
    CCCext ACO Setting default is .ccc

    Preventing agents from acting as cookie provider
    No Magic ACO Setting
    Remove .CCC Mime Type from Agent
    Rename CCCext to something and do NOT set that extension to be ignored
    Will result in a generic error
    Rename CCCext and set it to <ccc> which will get picked up by existing BadCSSChars
    Will result in the user getting sent to the CSSErrorFile

    Time restrictions on Session cookies
    CookieValidationPeriod ACO Setting
    Default is none which tells the policy server and web agents to use the standard timeouts
    Timeout from the time the agent asks the cookie provider for a session until the time it is returned

    ExpiredCookieURL ACO Setting Default is empty can forward users to an error page if the CookieValidationPeriod is exceeded

    Use a Session Server instead of placing the Session on the URL
    StoreSessionInServer ACO setting Default is No
    A single use cookie is placed into the session server and mapped to a GUID
    A GUID is passed to the cookie provider allowing the cookie provider to read the session
    As soon as the session is read it is deleted by the session store
    Requires a single session store database (the redirects happen faster then DB replication)

    There are also 2 other settings
    TrackCPSessionDomain
    CPCookieScope


  • 8.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Nov 30, 2012 04:34 PM
    Also the SiteMinder Agent does many things to check for other types of attacks

    Cross Site Scripting
    CSSChecking ACO Setting
    No By Default
    Blacklist of characters identified in BadCSSChars ACO
    Examples of Bach characters include “<“ “ ’ ” “>”
    Users redirected to the CSSErrorFile location


    Bad characters in URLS
    BadURLChars ACO Setting
    Default is commented out
    Blacklist of characters works up to the QueryString (?)
    // , ./ , /. , /* , *. , ~ , \ , %00-%1f , %7f-%ff , %25
    BadQueryChars ACO Setting
    Same as BadURLChars but applied after the Querystring (?)
    Default is commented out and empty


    Bad characters in Forms
    BadFormChars ACO Setting
    Default is commented out
    Default contains “<” “>” “&” “%22”
    Removes bad characters from the form data but lets the rest of the form pass



    ServerErrorFile will catch errors thrown by BadURLChars and BadQueryChars for error handling


  • 9.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Nov 30, 2012 04:36 PM
    And a few other SiteMinder session security settings:

    Using the Session store for centralized sessions can provide additional benefits
    Logout – once a session has been logged out using a logoffURI or a logout.fcc page, the session is marked as terminated
    If Agents have this session in the session cache it can take some time to propagate (1 Policy Server management and 1 web agent management cycle 90 seconds by default)

    Prevent the browser from using caching Pages
    If-modified-since or if-none-match headers from the browser
    AllowCacheHeaders ACO Setting
    Strips out these headers so the web server never tells the browser to use cached content
    Default is NO removing cache headers from the browser for protected resources only
    Yes allows all caching headers
    None removes all cache headers for protected and unprotected pages

    Prevent Proxies or browser from Caching content
    ExpireForProxy ACO Setting
    Default is NO
    YES allows you to add HTTP headers to the browser Telling Proxies not to cache the content
    Documentation says only for Proxy Servers but applies to browser also
    ProxyHeadersAutoAuth
    ProxyHeadersUnprotected
    ProxyHeadersProtected
    ProxyHeadersAuthAuth10
    ProxyHeadersUnprotected10
    ProxyHeadersProtected10

    The Agent performs a DNS lookup on the IP address
    Attacker can send a fake IP address as part of a request
    Agent does a DNS lookup which takes some time
    Threads are waiting on DNS servers
    DisableDNSLookups ACO Setting
    Default is to have DNS lookups enabled


  • 10.  RE: SiteMinder Cookies, their Usage, Contents and Security

     
    Posted Nov 30, 2012 07:15 PM
    Thanks AB for all your contributions here! Have a great weekend! :grin:


  • 11.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Feb 28, 2013 12:11 PM
    Do we have a paramenter in the ACO where we can capture the cookie to be persistent ( cookie should be active for about 7days) which should not be stored on the Users hard disk or browser, instead use a database as per the siteminder admins choice?


  • 12.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Mar 22, 2013 01:09 PM
    Do we have any parameter in ACO to enable "SMTRYNO" cookie?


  • 13.  RE: SiteMinder Cookies, their Usage, Contents and Security

    Posted Mar 22, 2013 01:15 PM
    SMTRYNO will be generated if the @SMRETRIES directive is in the logon.fcc file that is posted to. It needs to be a number > 1 so @smretries=99 for instance.