vADC Docs

What's the X-Mapping- cookie for, and does it constitute a security or privacy risk?

by on ‎02-22-2013 10:01 AM - edited on ‎06-11-2015 03:40 PM by PaulWallace (6,077 Views)

A user commented that Stingray Traffic Manager sometimes adds a cookie named 'X-Mapping-SOMERANDOMDATA' to an HTTP response, and wondered what the purpose of this cookie was, and whether it constitited a privacy or security risk.

 

Transparent Session Affinity

 

The cookie used used by Stingray's 'Transparent Session Affinity' persistence class.

 

Transparent session affinity inserts cookies into the HTTP response to track sessions. This is generally the most appropriate method for HTTP and SSL-decrypted HTTPS traffic, because it does not require the nodes to set any cookies in their response.

 

The persistence class adds a cookie to the HTTP response that identifies the name of the session persistence class and the chosen back-end node:

 

Set-Cookie: X-Mapping-hglpomgk=4A3A3083379D97CE4177670FEED6E830; path=/

 

When subsequent requests in that session are processed and the same sesison persistence class is invoked, it inspects the requests to determine if the named cookie exists. If it does, the persistence class inspects the value of the cookie to determine the node to use.

 

The unique identifier in the cookie name is a hashed version of the name of the session persistence class (there may be multiple independent session persistence rules in use). When the traffic manager processes a request, it can then identify the correct cookie for the active session persistence class.

 

The value of the cookie is a hashed version of the name of the selected node in the cluster. It is non-reversible by an external party. The value identifies which server the session should be persisted to. There is no personally-identifiable information in the cookie. Two independent users who access the service, are managed by the same session persistence class and routed to the same back-end server will be assigned the same named cookie and value.

Comments
by aveselovskyy
on ‎09-15-2013 05:04 AM

Hey guys

Just wanna share a couple of thoughts about X-Mapping cookie.

As for me usage of this cookie is a real vulnerability:

  1. It disclosures the fact, that we actually use load balancer in front of web application.
  2. It exposes provider and type of load balancer software (valuable for future exploits).
  3. We can't decipher internal host names using cookie's value, but we could send a whole bunch of requests and count distinct values in response. In this way we could predict the number of internal nodes behind the load balancer.
  4. And the most critical part - attacker can easily direct his requests to a particular node (usually it requires less effort to bring down individual node than whole cluster at once).

It would be great to hear some thoughts about these facts from you in response.

Thanks in advance

by
on ‎09-17-2013 07:19 AM

Hi Andriy,

You're exactly right in your statements above, and you need to make a judgement as to whether the concerns are serious enough that you look to an alternative to the Transparent Session Persistence method.

Points #1 and #2 are broad; there are lots of ways to 'fingerprint' the web infrastructure.  If you're concerned that the X-Mapping-Cookie is an obvious indicator that Stingray is in use, you could use an alternative session persistence method (e.g. IP, SSL-Session-ID, or Universal) that does not leave any external fingerprint.  Check out the list of session persistence methods in this doc Feature Brief: Session Persistence in Stingray Traffic Manager that do not use client-side cookies.

Points #3 and #4 relate to the ability to exploit session persistence to target specific nodes in the cluster. This is a consequence of any session persistence method, and you can mitigate against it by deploying session persistence selectively - see HowTo: Controlling Session Persistence for a simple example. If an attacker is mounting a volume-based attack, exploiting session persistence to target an individual node, then the best mitigation would be rate limiting, using the techniques and examples in Feature Brief: Bandwidth and Rate Shaping in Stingray Traffic Manager.

Finally, it may be possible to inspect and modify the X-Mapping cookie using trafficscript.  You may be able to encode it further once it is set using a response rule, and then decode it in a request rule before the load-balancing decision is made.  I'm not completely sure if this is possible, but perhaps an interesting exercise to try!

I hope that these explanations help - thanks for pointing out these concerns

Best regards

Owen

Contributors