Web

SESSION MANAGEMENT

Virtually every non-static Web application embodies stateful behavior such as identifying individual users, enforcing access control rules, and distinguishing simultaneously submitted requests. Due to the stateless nature of HTTP, this stateful behavior is enabled on top of HTTP by introducing sessions. Sessions link multiple requests from the same client together and allow stateful information to be accessed and updated during the course of that session. The de facto implementation of sessions consists of a server-side stored session state, for which the server generates a random, unique session identifier (SID). The client is instructed to include the assigned SID with every request, allowing the server to link multiple requests from this client to the same session. There are two common ways a Web application can instruct the client to include a SID: cookies and parameters.

COOKIES AS SESSION IDENTIFIERS

Cookies are key/value pairs belonging to the domain that sets them, potentially extended by certain options (e.g. Path, Secure, etc.). The browser keeps track of cookies in the so-called cookie jar. When the browser sends a request to a certain domain, it attaches all known cookies for that domain using the Cookie request header. Traditionally, cookies are set by the server using either the Set-Cookie response header, by embedding a Set-Cookie meta tag in the body, or by including JavaScript that sets a cookie when executed by the browser. Cookies typically belong to the domain that sets them (e.g. www.example.com), but using the Domain option, they can also be bound to a parent domain (e.g. .example.com), in which case they belong to all subdomains of example.com. This feature is often used to share the same cookies among different parts of an application (e.g. login.bank.com and payments.bank.com). Setting the Domain option to a top-level domain (e.g. .com) is not allowed.

Implementing session management using cookies is straightforward: a session is typically created by the server after receiving the first (cookieless) request, and the generated SID is attached as a cookie to the response. The browser stores the cookie containing the SID and attaches it to every request going to this specific domain. Upon receiving a request containing a cookie with a SID, the server can link the request to the associated session. A new SID can easily be assigned by sending the client a new cookie with the same name but a different value, which overwrites the old value.

PARAMETERS AS SESSION IDENTIFIERS

Since not all clients support cookies, or cookie support can be explicitly disabled by the user, an alternative approach is to include the SID as a parameter in every request to the server. Examples are to include the SID as a parameter in the URL of a link, or as a hidden field in a form element. Maintaining a session this way requires the server to ensure that all URLs pointing to its own domain contain the SID of the associated session. When the user opens a URL with an embedded SID (e.g. by clicking on a link), the browser sends a request containing the embedded SID, allowing the server to extract the SID and link the request to the associated session. Popular Web frameworks offer embedded support for session management, which includes both cookie-based and parameter-based session management. Sites running on top of such a framework can easily support the parameter-based fallback mode if desired.

ATTACKS ON SESSION MANAGEMENT

Attacks on session management are popular since they offer a high reward for the attacker. Successful attacks can involve the attacker making specific requests in the user’s name, or an attacker having full control over the user’s session, allowing him to access all information and perform all actions available to the user. Concrete attack examples include session hijacking and cross-site request forgery (CSRF). Existing work proposes specific client-side countermeasures to prevent both session hijacking and CSRF attacks. We focus on session fixation and propose a client-side countermeasure against this attack. To the best of our knowledge, Serene is the first concrete proposal for client-side protection against session fixation attacks.

President

The divine scriptures are God’s beacons to the world. Surely God offered His trust to the heavens and the earth, and the hills, but they shrank from bearing it and were afraid of it. And man undertook it.
Back to top button