Remained MRHSession cookie cause login issue to Vmware horizon at 2nd access with MS Edge

[Sakiy]

We use APM for Horizon PCoIP gateway. We send login credential by POST to login webtop for Horizon VDI.

1st access is always OK. But if it is access 2nd or later times without closing MS edge browser, it failed. When IE was used, there was same issue, but we can launch IE with "noframemerging" option. So it was possible to start session without previous session cookie. With useing "noframemerging" option, the 2nd time access issue was avoided.

With MS Edge, there is no "noframemerging" , if webtop was accessed without closing all Edge, authenticaiotn with POSTed credential fails at 2nd time. 

In order to avoid the problem, I made a jsp to access to https://[webtop URL]/my.logout.php3 first and redirect to webtop because I found that the my.logout.php3 delete  MRHSession cookie. If MRHSession does not exist, Webtop login with Posted credential works all the time.

This works, however, we uses client side inspection by APM and client side inspection run times with this way.  This is not nice because it takes time to run client side inspection.

Is there anyway to delete MRHSession cookie before accessing virtual server?

[F5_Design_Engineer]

Hi @Sakiy ,

You want to remove BIG-IP cookies from server-side connections and prevent the cookies from being sent to the origin web servers (OWS).

Description

BIG-IP system cookies are unlikely to be relevant or problematic to an OWS that receives connections from the BIG-IP system.

 ==================================================================

You can create an iRule to remove an offending BIG-IP cookie from client-side connections.

To do so, you can use an iRules similar to the following examples:

iRule to remove AVR cookies

when HTTP_RESPONSE_RELEASE {
  set cookies [HTTP::cookie names]
  foreach aCookie $cookies {
        if {$cookiename starts_with "avr_"} {
      # Remove AVR Cookies
      HTTP::cookie remove $aCookie
    }
  }
} 

iRule to remove BIG-IP ASM cookies

when HTTP_RESPONSE_RELEASE {
  set cookies [HTTP::cookie names]
  foreach aCookie $cookies {
    if {$aCookie matches_regex {^TS(?:[0-9a-fA-F]{6,8})(?:$|_[0-9]+$)}} {
      # Remove ASM Cookies
      HTTP::cookie remove $aCookie
    }
  }
}

Recommended Actions

Configure an iRule to remove a BIG-IP cookie from client-side connections

Impact of procedure: Adding an iRule increases the resources used by the associated virtual server. Depending on the type and volume of the connections, this processing may introduce noticeable latency. F5 recommends testing any such changes in an appropriate environment. 

1. Log in to the Configuration utility.
2. Navigate to Local Traffic > iRules.
3. Click Create.
4. Provide a name for the iRule.
5. For Definition, enter the iRule.

For example, to remove ASM cookies, enter the following iRule:

when HTTP_RESPONSE_RELEASE {
   set cookies [HTTP::cookie names]
   foreach aCookie $cookies {
         if {$aCookie matches_regex {^TS(?:[0-9a-fA-F]{6,8})(?:$|_[0-9]+$)}} {
      # Remove ASM Cookies
      HTTP::cookie remove $aCookie
    }
  }
}

1. Click Finished.
2. Navigate to Local Traffic > Virtual Servers.
3. Click the appropriate virtual server.
4. Click the Resources tab. 

Note: For BIG-IP 12.x and earlier, on the Virtual Server List page, click Edit in the Resources column for the virtual server you want to use.

1. For iRules, click Manage.
2. In the Available list, click the name of the iRule you defined in step 4 and move it to the Enabled list.
3. Click Finished.

 ==================================================================

However, if your specific environment requires it, you can create an iRule to remove an offending BIG-IP cookie from server-side connections.

To do so, you can use iRules similar to the following examples:

iRule to remove AVR cookies

when HTTP_REQUEST_RELEASE {
  set cookies [HTTP::cookie names]
  foreach aCookie $cookies {
        if {$cookiename starts_with "avr_"} {
      # Remove AVR Cookies
      HTTP::cookie remove $aCookie
    }
  }
}

iRule to remove BIG-IP ASM cookies

when HTTP_REQUEST_RELEASE {
  set cookies [HTTP::cookie names]
  foreach aCookie $cookies {
    if {$aCookie matches_regex {^TS(?:[0-9a-fA-F]{6,8})(?:$|_[0-9]+$)}} {
      # Remove ASM Cookies
      HTTP::cookie remove $aCookie
    }
  }
}

MRHSession

BIG-IP APM Session ID 32 random hex digits.

Session cookie design

The MRHSession cookie uses 32 randomly generated hex digits to generate the session ID. The MRHSession cookie is designed to ensure that only the BIG-IP APM controller and client can view the full session ID. The following safeguards ensure that a third party will not have access to any of the session IDs in use.

• The session ID value is generated securely using a proprietary algorithm. The algorithm creates session ID values that are not reversible or predictable and provide unique session IDs per client.
• Session cookies are set only after the SSL handshake between the BIG-IP APM system and the user has completed, ensuring that the MRHSession cookies are protected from interception with SSL encryption.
• To ensure that the client browser will not send session cookies unencrypted, the HTTP header that the BIG-IP APM uses when sending the session cookie is set with the secure option.  For example:

  Set-Cookie: MRHSession=d896020385383db9ece7ac6d41f45923; path=/; secure

  Note: Vulnerability scanners may detect that the secure flag is not set on all of our cookies. When the cookie is deleted, the secure flag is not set. The value of the cookie is set to deleted, and the expiration date is set to 01/01/1970 so the browser will discard the cookie.

  For example:

  Set-Cookie: MRHSession=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT;path=/

• F5 has designed BIG-IP APM session cookies with inherent security properties.
   
  • Session cookies are stored in the client's device memory; accessing this data requires access to the client device memory of the account on the user's device.
  • Session cookies expire when the user's browser is closed.
    Note: Some browsers may include features that let you restore a session. This may keep you logged in to websites that you were logged in to before you closed the browser. For example, in Firefox, refer to Restore previous session - Configure when Firefox shows your most recent tabs and windows. You can configure your browser to disable this feature. For more information, refer to your browser's documentation.

• Each login to the BIG-IP APM system triggers new session cookies and a session ID to be generated.

• You can configure the following options for BIG-IP APM cookies in the Configuration utility:

  • Access > Profiles / Policies > access profile name > SSO/Auth Domains (BIG-IP APM 13.x and later) 
  • Access Profiles > Access Profile Lists > access profile name > SSO/Auth Domains (BIG-IP APM 12.x and earlier)
     
    • Secure: If the BIG-IP APM virtual server is configured with a Client SSL profile, select Secure (default setting) when configuring the BIG-IP APM SSO/Auth Domain cookie settings.
    • Persistent: Session cookie persistence functions only on BIG-IP LTM and APM deployments. For BIG-IP APM deployments with connectivity resources (such as Network Access, Portal Access, etc.), you cannot set BIG-IP APM cookies as Persistent. This is by design, as session cookie persistence can present a security risk. For some deployments of the BIG-IP APM system, as with Microsoft SharePoint, cookie persistence may be required. When you select cookie persistence, persistence is hard coded at 60 seconds.
    • HTTP Only: For BIG-IP APM deployments with connectivity resources (such as Network Access, Portal Access, etc.), do not set BIG-IP APM cookies with the HTTP Only flag.
       
• By default, F5 does not set the Http Only attribute for BIG-IP APM session cookies. BIG-IP APM session cookies and BIG-IP APM cookie handling is designed to ensure that resources other than the BIG-IP APM and required client side applications cannot access the cookie contents; the BIG-IP APM system does not pass the cookie to the destination resources. The BIG-IP APM rewrite/reverse proxy engine processes all content between users and the destination resources, ensuring that non-BIG-IP APM resources have no direct access to session cookies. You can configure BIG-IP APM 11.2.0 and later access profiles to use the Http Only attribute; you should consider the following factors when setting the attribute:
   
  • When the Http Only attribute option is enabled, only BIG-IP LTM and APM (a BIG-IP LTM virtual server with an access policy) is supported.
  • An access profile configured with the Http Only attribute will impede session traffic for Network Access and Network Access Tunnels, and the BIG-IP system will not run Access Policies with client side checks or actions.

    Note: Some vulnerability scanners may trigger a false positive based solely on session cookies not set with the Http Only attribute.

• In BIG-IP 11.2.0 and later, during the course of an access policy evaluation, the first 24 hex digits of the session ID are randomly rotated to prevent session hijacking and fixation attempts. This feature can cause issues with older clients or deployments using iRules if they assume a fixed session ID value. After Access Policy evaluation, the session ID remains static. This feature is controlled by the apm.rotatesessionid database variable and has a default value of enable.

You can refer

https://community.f5.com/t5/technical-forum/irule-to-clear-session-when-traversing-to-new-apm-profil...

Using an iRule to remove a BIG-IP cookie from server-side connections

Impact of procedure: Adding an iRule increases the resources used by the associated virtual server. Depending on the type and volume of the connections, this processing may introduce noticeable latency. F5 recommends testing any such changes in an appropriate environment.

1. Log in to the Configuration utility.
2. Navigate to Local Traffic > iRules.
3. Click Create.
4. Provide a name for the iRule.
5. For Definition, enter the iRule.

   For example, to remove AVR cookies, enter the following iRule:

        when HTTP_REQUEST_RELEASE {
          set cookies [HTTP::cookie names]
          foreach aCookie $cookies {
                if {$cookiename starts_with "avr_"} {
              # Remove AVR Cookies
              HTTP::cookie remove $aCookie
            }
          }
        }

6. Click Finished.
7. Navigate to Local Traffic > Virtual Servers.
8. Click the appropriate virtual server.
9. Click the Resources tab.

   Note: For BIG-IP 12.x and earlier, on the Virtual Server List page, click Edit in the Resources column for the virtual server you want to use..

10. For iRules, click Manage.
11. In the Available list, click the name of the iRule you defined in step 4 and move it to the Enabled list.
12. Click Finished.
    
    HTH

[Kai_Wilke]

Hi Sakiy,

I always use an iRule to fix APMs rather broken errorhandling if MRHSession cookies from previous APM sessions remain in browser. I believe you could use the very same iRule to fix your problems...

when HTTP_REQUEST {

	# Fixing APMs complains when restart of APM sessions occur....

	if { [HTTP::cookie value "MRHSession"] eq "" } then {

		# APM cookie not present so we do nothing...	

	} elseif {  [ACCESS::session exists -state_allow [HTTP::cookie value "MRHSession"]] } then {

		# APM cookie present and already authenticated. Pass the cookie to APM...		

	} elseif { ( [HTTP::path] starts_with "/public/images/customization/" ) 
			or ( [HTTP::path] starts_with "/saml/sp/profile/post/acs" ) } then {

		# APM cookie present but not authenticated and requesting APM resources which are not hidden by APMs HUD filter. Do nothing...	

	} else {

		# APM Cookie present but not authenticated. Killing existing APM session (if exists) and remove MRHSession cookie from the ongoing request...

		ACCESS::session remove
		HTTP::cookie remove "MRHSession"

	}

}

The iRule simply removes inactive MRHSession cookies from those requests which are not hidden by APMs HUD Filter (aka. Request to APM itself). 

Give it a try...

Cheers, Kai