From a security point of view, is it okay to read foreign (untrusted) cookies (from 3rd parties on the Internet) on your internal (trusted) network, or should you only read them within the DMZ areas of your network environment?

The reason I'm asking is because we want to allow people to access our web services from the Internet. The web services will be on our internal network and we want to use F5 BIGIP (or similar) systems to decrypt the HTTPS traffic, read the cookie (for load balancing/routing purposes) and then re-encrypt the traffic, before passing it onto the web server.

  • This sounds quite similar to this question. I'm not sure what you mean my "reading the cookie". What is reading them in your scenario?
    – Bruno
    Commented May 4, 2012 at 10:22
  • Hi Bruno, No, my question is very different because I'm talking about reading cookies on inbound traffic (to load balance to back-end web servers based on that, rather than by IP address - which doesn't work if the user is behind a NAT). An F5 BIGIP server, or SAP Web Dispatcher server could terminate the HTTPS connection, read the cookie and re-encrypt the HTTPS connection. Thanks.
    – Techboy
    Commented May 4, 2012 at 10:33
  • I don't really understand what the security risks you think there may be by reading cookies coming from clients, especially if the connection between them and your head node was over HTTPS.
    – Bruno
    Commented May 4, 2012 at 10:36
  • 1
    Playing StackExchange against your manager. Cunning :-) Don't trust advice you get here blindly, though, it comes with no warranty whatsoever.
    – Bruno
    Commented May 4, 2012 at 11:06
  • 1
    @acidzombie24 sslsniff is an open source MITM tool by Moxie Marlinspike for doing just that, there are also several commercial proxy servers with such capabilities. Basically all it requires is the encryption keys and certificates to use for that server or a CA certificate and keys for generating valid certificates on the fly (if targeting multiple domains and the like).
    – ewanm89
    Commented May 4, 2012 at 19:05

2 Answers 2


Cookies which are sent by the client to your server are just parts of the requests sent by the client to your server, and, as such, should be considered as "potentially hostile" by default. If the client may be an attacker (and it would be quite naive to dismiss this possibility), then anything which the client sends is suspect and could be crafted in order to maximize disruption or do even more evil things. SQL injection attacks, for instance, are a common example of attacks in which the client sends such "bad" requests. Cookies, in that respect, are no different. A cookie is stored on the client side, and the client can alter his cookies as he sees fit.

Since a cookie is meant to be stored "as is" and sent back unaltered (that is, that's what honest clients do), you can include in your cookies a message authentication code: that's a kind of checksum which uses a secret key. This way, your server could verify (by recomputing the checksum on an incoming cookie value) whether the cookie is "genuine", i.e. is a cookie value which was, at some point in time, sent by the server to a client (not necessarily the same client ! If one client can be hostile, two can be hostile as well, and collude). Such a distinction between genuine and crafted cookies can help in protecting your server against hostile cookies; but it won't totally replace care, and, of course, a request contains other elements besides cookies.

Cookies (sent over HTTPS) have security value in another attack scenario: if the client is honest and manages its security properly, then the cookies your server sends to the client will be unaltered during their transit, and will come back untouched, and, moreover, the cookie contents will remain unknown to outsiders (HTTPS relies on SSL/TLS which provides confidentiality and integrity for data in transit). HTTPS protects your server and the client against third parties; it does not protect your server against the client itself.


I'm not sure I fully understand the question. What I gather is that you have a clients connecting from outside via HTTPS to a head node (F5) that terminates this SSL/TLS connection. Then, this head node/reverse proxy makes another connection (possibly over SSL/TLS) to other web servers within your network. (If you're worried about securing that internal connection, this question would be relevant, but this doesn't seem to be the case.)

Since your head node deciphers the entire SSL/TLS traffic, it's able to read everything. Cookies are only a small part then (why not worry about the entire requests/responses?). You'll always need to trust your SSL/TLS termination point. If it then uses the cookie to dispatch the request, so be it, it's legitimately in full control of the request anyway.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .