Hardening the sticky cookie module

[vankoven]

Attacker may use the same sticky cookie value to access all vhosts protected by Tempesta. The issue greatly affects per-vhost sticky cookie behaviour, so it's highly linked with #685 and probably should be done with it.

Sample scenario:

• Attacker sends request to vhost A.com;
• Tempesta starts sticky cookie challenge: send redirect and Set-Cookie: __tfw=123;
• Attacker follows the redirect with the cookie __tfw=123 set;
  -Tempesta sends normal reply (from cache or proxied from the backend server.
• Attacker send request to vhost B.com, but uses the same sticky cookie __tfw=123
• Sticky cookie is valid, so Tempesta serves the request from cache or from backend server.

Passing the sticky cookie challenge means that the client - is normal client, not a bot, and we should process all requests from this clients normally. But cookies has a scope, (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Scope_of_cookies for details) and normal browsers won't use the same cookie for different vhosts. Since normal browser won't follow the scenario above, the client should be treated as an attacker and should be blocked.

We must also protect our responses with Set-Cookie: header set with Cache-Control: private header in order to deny caching the responses by intermediate caching proxies. Otherwise the cookie value will be saved in the cache of intermediate proxies.

At the first sight we must assure that the target vhost for the request conforms the sticky cookie name, and block requests that uses cookies for other vhost. But such solution has a huge performance impact. To allow fast sticky cookie scheduler to work, we must process sticky cookie before http_chain (see #1043). Searching among all per-vhost cookies not very cheap, and matching among http_chain rules is expensive (keep in mind use cases with millions of protected vhosts). The solution that looks nice:

• search for known per-vhost cookie in the request. It's cheaper than the http_chain scans: no such variety of operations and comparisons, optimal algorithm may be used.
• if cookie is found: validate the scope of the sticky cookie: need to check only uri and domain; assign the resulting vhost to the request, http_chain scans are not needed
• if cookie is not found: just fallback to the http_chain scans.

[krizhanovsky]

Let's make the comment from #1074

It seems the problem is that JS and cookie challenge can not be per-vhost, so please make them per-vhost'able. If the per-vhost challenge requires more than couple of days, then please create a new issue for 1.1 milestone.

as part of this issue since it's also about per-vhost logic.

It seems we have to introduce some data structure to resolve cookies to vhosts, but it's very unwished to introduce one more data structure like a trie just to match cookies. I propose to encode vhost in the cookie, either in cookie name (e.g. __tfw_<vhost>=..value..) or in value (e.g. __tfw=<vhost><stuff><hash>), and/or extend HTTPtables for fast matching of many cookies (in this case the issue depends on #732 (Fast HTTP match)). The cookeis matching is the only special in that it's used for quick sessions scheduling before HTTPtables, but it seems we can reuse code from HTTPtables.

[vankoven]

The A-B scenario was closed in #1354 since the full chains lookup is performed before sticky session processing. I hadn't found a way to resolve the A-B and similar security problems without full http_chain scans, the flexibility of the chains give too many ways of L7 filtering, and trying to use only cookies for that is efficient. E.g. a client with a valid cookie may request denied URIs that are blocked by http_chains; iptables marks won't be added to skbs if the chains are bypassed and so on.

The only requiremt left in the task is about cache-control.

[vankoven]

from #1383 (comment)

Also, take care of foreign cookies: if backend sets cookie for a client, never store the set-cookie header in the cache. Probably the whole response shouldn't be marked as cacheable if Set-Cookie header is set or it's life time can be set to 0 to enforce sending authorise requests to backend server. Another option - is to alter Cache-Control header if it allows to cache the header.

Actually it's backend fault if they allow caching Set-Cookie header. But we should take care for them and protect them from bugs. Other servers does pretty the same