People's Newsroom

CLIENT-SIDE PROTECTION AGAINST SESSION FIXATION

Even though adequate protection techniques and countermeasures exist, Web applications do not implement them, leaving the user vulnerable. Serene, a client-side countermeasure against session fixation, that will protect the user against session fixation attacks, regardless of the security precautions taken by any target application. Serene does not depend on the user to make security decisions, since the user cannot be expected to have the expertise nor the time to make a decision for each application or request. 

GENERAL APPROACH

The general approach of protecting against session fixation attacks is to prevent potentially fixated SIDs from being sent to the server. If a fixated SID never reaches the server, session fixation is simply not possible. This general approach, as depicted in Figure, is applicable for both cookie-based and parameter-based session management. For cookie-based session management, Serene keeps track of all legitimately set cookies that contain a SID in an internal database. These cookies are found in the Set-Cookie header, part of the response. Next, Serene scans each outgoing request for attached cookies, by investigating the Cookie header. Any attached cookies that contain a SID must also appear in the internal database of legitimate SIDs for the target site. In case a cookie containing a SID is not present in the internal database, it is stripped from the outgoing request. The reasoning behind this approach builds on the fact that it is very unlikely for a server-generated session identifier to be set in other ways than through a header.

Mapping the attack vectors discussed earlier to this approach shows that cookies containing a SID set through JavaScript or meta tags are not known in the internal database, and thus not sent to the server. This holds both for the single domains as well as for the subdomain case. The only remaining attack vector is through header injection in a single domain, a highly unlikely scenario, or through header injection from a subdomain. To protect applications with parameter-based session management, incoming pages are scanned for embedded SIDs (e.g. in URLs or as hidden form fields) that identify a session within the domain sending the response. Similar to cookies, these SIDs are stored in the internal database. Outgoing requests are also scanned for any embedded SIDs (e.g. in the URL or in the POST body), and SIDs not present in the database is removed from the request.

The attack vectors described earlier are foiled by this approach. An externally injected link will contain a SID that is unknown to Serene, so it will be removed. Similarly, an attacker page embedding a SID in a URL to the target domain is not a logical scenario: a SID should be set by the domain that wants to maintain a session, not by another domain. Therefore, such SIDs are not stored in the database, so attaching them to a request will not be allowed by Serene. Additionally, SIDs injected by a script will not yet be present when Serene examines the response, so they will not be stored in the database, therefore they will not be allowed on an outgoing request. Finally, if the attacker injects HTML code containing a fixated SID directly in the target application, it will collide with SIDs added by the application. Serene detects such collisions and either use a previously-stored SID or removes all offending SIDs from the page.

PARAMETER-BASED EXCHANGES

Complex Web applications often share SIDs or SID-like tokens across domains using cross-domain requests with embedded parameters. Common examples are single sign-on services and applications that span multiple domains (e.g. google .com and google.be, etc.). Such a cross-domain interaction pattern shows similar characteristics as a parameter-based session fixation attack and is also detected and prevented by Serene’s general approach. From a security point of view, Serene’s general approach is quite effective, since it stops potential session fixation attacks. From the usability point of view, however, breaking functionality is to be avoided. Therefore, we slightly relax the general approach for SIDs embedded as a parameter: we allow them to be sent to the server only once and make sure that they are not used to maintain a potentially fixated session. Practically, Serene remembers unknown SIDs embedded as a parameter when sending the request and makes sure these unknown SIDs are removed from the corresponding response if present (e.g. in an element, script, header, etc.). This relaxation (Figure 4.2b) allows a valid token to be exchanged, and prevents a fixated SID from doing harm. Even if a fixated SID is sent to the server, it can never be used to establish a fixated session, since Serene will prevent it to be used on subsequent requests.

SESSION IDENTIFIER IDENTIFICATION

Serene’s approach depends on the capability to distinguish session identifiers from other cookies and parameters. Earlier approaches to tackle this problem are not directly applicable for reasons. Therefore, we used these approaches as inspiration for an elementary SID identification algorithm. Below, we discuss the way the algorithm works. The first step in the algorithm is to check whether the key matches an extensive list of 45 known session identifier names. If not, we check whether the key/value pair passes all of the following three heuristics:

1. The key has to include an obvious part of a SID name (e.g. sess or id)

2. The value has to be sufficiently long (i.e. 10 or more characters).

3. The value has to be sufficiently random.

Each of the three heuristics serves a specific purpose. The first heuristic is required to rule out key/value pairs that contain a long, seemingly random value, but are in no way related to a SID. The second heuristic rules out short identifiers, such as product or article identifiers. The third heuristic rules out any non-random values since they cannot serve as a valid session identifier anyway. Any key/value pair not matching these heuristics is either not session-related, or not fit to serve as a session identifier. For instance, a short or non-random value is easily brute-forced.

PROTOTYPE IMPLEMENTATION

The prototype of Serene is implemented as a Firefox add-on, available for any modern version of Firefox. Once Serene is installed, it protects against session fixation attacks without requiring any configuration. Due to the extensive add-on support available within the Mozilla framework, the implementation of Serene is fairly straightforward. Cookie inspection and manipulation are done through the HTTP channel, which provides access to the request before it is sent out and to the response before it is processed. The HTTP channel is also used to detect outgoing SIDs embedded as parameters. Incoming parameters containing SIDs are extracted from the page contents and potentially harmful tokens are removed from the page before it is processed.

Back to top button