Update 10/18/2018: Google Chrome actually removed Token Binding support in version 70 so you’ll have to be on an older version to see this work in action, or use MS Edge, also see here. See here to learn how to run two Chrome versions side-by-side.
Today the so-called Token Binding specifications have formally been promoted to proposed standards RFC by the IETF. Essentially those specs define how to securely bind tokens to the communication channel running between a client and a server. As simple as that sounds, it is an extremely important step forward in web security: tokens are used everywhere across the Internet today (e.g. for SSO, APIs, Mobile Apps) but moreover, the ubiquitous HTTP cookie also falls into the security token category.
In this post we’ll focus on securing HTTP cookies in Web Applications. HTTP cookies are pervasive on the web yet the vulnerability window for stealing such a cookie is usually larger than the window for stealing a security token, the damage is typically larger and abuse is harder to detect. Applying Token Binding to HTTP cookies closes a vulnerability in the web application landscape and prevents session hijacking by stealing a session cookie. See for example a class of XSS attacks that will now fail: https://www.hackeroyale.com/cookie-stealing-xss/ but also retrieving a session cookie from application/server logs, from the network, or through malicious client software etc. is no longer effective.
Implementing the Token Binding protocol itself in your application by interfacing with the TLS layer is complex and may go wrong easily. So how can an application leverage Token Binding today without jumping through time-consuming and dangerous hoops . Well, applications on or behind Apache are catered for by mod_token_binding: they can leverage a header or environment value set by mod_token_binding in their session cookie (or in other tokens they generate for that matter). The hard protocol security bits are dealt with by mod_token_binding and a trivial 2-step implementation process remains for the application itself. See below for a sample in PHP:
- At session creation time: put the Token Binding ID provided in the environment variable set by mod_token_binding into the session state
$tokenBindingID = apache_getenv('Sec-Provided-Token-Binding-ID');
if (isset($tokenBindingID)) {
$_SESSION['TokenBindingID'] = $tokenBindingID;
}
2. On subsequent requests: check the Token Binding ID stored in the session or token against the (current) Token Binding ID provided in an environment variable
if (array_key_exists('TokenBindingID', $_SESSION)) {
$tokenBindingID = apache_getenv('Sec-Provided-Token-Binding-ID');
if ($_SESSION['TokenBindingID'] != tokenBindingID) {
session_abort();
}
}
Et voila, we’ve bound the PHP session cookie to the TLS channel with the Token ID provided by mod_token_binding that’s all there is to it!
As another example is mod_auth_openidc, the OpenID Connect RP client for Apache HTTPd. This module already leverages this functionality for its own session cookie, its state cookie and the id_token, the latter if only supported by the Provider.
Anyone using mod_auth_openidc should look to deploy it in conjunction with the Token Binding module now! (but be aware that you need to upgrade your Apache server to >= 2.4.26 and build/deploy it with a OpenSSL >= 1.1.1 stack)
But also legacy applications may use Apache HTTPd with mod_auth_openidc deployed as a Reverse Proxy in front of their origin server so that their own session can only be started/accessed through an authenticated OIDC session cookie that leverages Token Binding. That makes them now effectively use Token Binding to protect themselves against session hijacking without touching the application and/or their own application session cookie [1].
Looking forward to lots of happy mod_token_binding usage!
[1] Note that the users’s browser also needs to support Token Binding to leverage all of this good work, but Microsoft’s Edge and Google’s Chrome already do this and support in other browsers such as Firefox is near.
Hans Zandbelt 