1

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.

Techboy
  • 113
  • 4
  • This sounds quite similar to [this question](http://security.stackexchange.com/q/14334/2435). I'm not sure what you mean my "reading the cookie". What is reading them in your scenario? – Bruno May 04 '12 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 May 04 '12 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 May 04 '12 at 10:36
  • I don't think there are any risks from reading cookies, but my project manager does. That's why I have asked the question on here :-) – Techboy May 04 '12 at 10:51
  • 1
    Playing StackExchange against your manager. Cunning :-) Don't trust advice you get here blindly, though, it comes with no warranty whatsoever. – Bruno May 04 '12 at 11:06
  • I never heard of reading https data and reencrypting. Are you sure it is possible? i am thinking no it isnt. Not for https traffic –  May 04 '12 at 18:45
  • 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 May 04 '12 at 19:05
  • @ewanm89: If you had the keys for the domains wouldn't that make https completely pointless as untrusted sites can pretend they are you? Than there is the whole MITM attack with stealing credit card info in a https session. I don't understand how you would get keys unless its your own domain. I'm still pretty confused. Are you talking about keys you pretend is on that domain? and install a publisher cert on every machine on the network? i'm fairly confused –  May 04 '12 at 19:43
  • @acidzombie24 Yes it is possible - see http://help.sap.com/saphelp_nw04s/helpdata/en/d8/a922d7f45f11d5996e00508b5d5211/frameset.htm and http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_http_ssl.html – Techboy May 04 '12 at 22:58
  • @acidzombie24 In reverse proxy as specified it is ones own domains, technically the keys don't have to match all it needs is the root CA to be trusted in the browser. This has good uses (reverse proxy for load balancing, or maintaining sessions on a single server), bad uses (MITM attack on all SSL connections, think government monitoring), questionable uses (corporate monitoring, where employees have agreed all data will be monitored but don't understand just how far reaching the company is being). – ewanm89 May 04 '12 at 23:12

2 Answers2

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.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
1

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.

Community
  • 1
Bruno
  • 10,875
  • 1
  • 39
  • 61