Symantec Access Management

 View Only

Tech Tip : CA Single Sign-On : Cookie Replay prevention

  • 1.  Tech Tip : CA Single Sign-On : Cookie Replay prevention

    Broadcom Employee
    Posted Jun 23, 2015 10:47 AM

    Every/any application that manages session via cookie is subject to replay attacks. Single Sign on has multiple embedded features that can help preventingCookie Replay.

     

    1) Implement a Session Store

    2) Configure your Realms to use the Session Store, by configuring the Realm to use Persistent Sessions.

    3) Configure a Logoff URI ( configuration with Logoff URI without the session store implemented will allow you to replay the cookie and there is no other way to resolve this unless by setting the

    session store) . If set with Session Store ,The Logoff URI will set the Cookie as LOGGEDEOFF in the session store and it can no longer be replayed. Moreover, for the issue with Local attack, the perpetrator would need to

    have physical access to the computer and the user would need to leave the machine logged onto the network, unlocked and unattended.

     

     

    -->To Prevent Replay attack from other machines, please refer to the document below as well as the explanation listed for the IP checking settings

     

        a) "Header Variables and End-User IP Address Validation"

     

     

    The Web Agent can use a custom HTTP header to determine a user s IP address instead of using the REMOTE_ADDR variable. In your case and because of the usage of a Proxy , Web Agent will need to be configured to look for that

    header on an incoming request, the Agent uses that header as the source of the client IP information.

    IP checking is implemented using two parameters:

     

     

        1) CustomIpHeader each entry specifies an HTTP header that the Web Agent should look for to find the requestor's IP address. for example, HTTP_ORIGINAL_IP. You can define this setting centrally, in an Agent

           Config Object or locally, in a configuration file. For central agent configuration, you can designate this parameter as a multi-value setting. For local configuration, each entry should be added on a separate line. For example:

     

     

    CustomIpHeader="HTTP_ORIGINAL_IP"

    CustomIpHeader="HTTP_CLIENT_IP"

     

     

    Note: The CustomIpHeader parameter can be used without a proxy address list being defined; however, the proxy definition list cannot be used without at least one custom IP header defined.

     

     

        2) ProxyDefinition each entry specifies the IP address of a proxy (such as a cache device) that requires the use of a custom HTTP header to resolve requester IP addresses. If no value is specified for this parameter,

        the default is an empty string.No maximum length is enforced for this parameter, and the value may be any string that contains a valid IP address, for example, 111.123.23.11. Do not enter server names

           or fully-qualified DNS host names. You can define this setting centrally, in an Agent Config Object or locally, in a configuration file. For central agent configuration, you can designate this parameter

           as a multi-value setting. For local configuration, each entry should be added on a separate line. For example:

     

     

    ProxyDefinition=111.12.1.1

    ProxyDefinition=112.11.2.2