HTTP sessions & security

The HTTP 1.1 protocol itself is stateless (e.g., has no inherent support for persistent sessions). Yet many web applications add sessions to become stateful.

What is a session? What is statefulness?

How do they impact security on the web?

Sessions are a correlation of requests for individual web pages/data (“hits”) into a sense of an overall “visit” for a client during a time span, but also retain some memory between events. They typically consist of a session ID coupled with its data indicating current state. Classic examples include logins, showing previously viewed items, and shopping carts.

The reason why HTTP applications must add sessions is related to how software works: software often changes how it appears or acts based upon:

Input you supply (e.g. a mouse click or a data file)
System events (e.g. time or availability of a network connection)
Current state (i.e. the product of previous events—history)

At each time, some inputs/actions are known to be valid and possible, while others are not. Without memory of history to define the current context, which actions are valid and possible, and therefore how it should function, cannot be known.

When software cannot function without memory, it is stateful. Many important features—denying access if a person is not currently logged in, for example, or shipping what has been added to a shopping cart—are stateful, and therefore can’t be supported by purely stateless HTTP according to the original RFC. Such features require that web apps augment the HTTP protocol by adding a notion of session memory via:

Cookies per RFC 2965 (http://tools.ietf.org/html/rfc2965)
Hidden inputs
Server-side sessions
Other means (see Authentication styles)

Because memory is an accumulation of input, sessions have security implications.

Can a different client easily forge another session?
Are session IDs reused in encrypt form data, thereby weakening the encryption?
Are session histories used to check for invalid next URLs or inputs (state transitions)?

When sessions are not protected to prevent misuse, attackers can use software in unexpected ways to expose vulnerabilities.

For example, let’s say there is a vending machine full of snacks. You must first insert the proper amount of money before the machine will give you a selected snack. If you provide an insufficient amount of money for the selected snack, the machine will do nothing.

The vending machine is designed so that it must be in a state in which it has received enough money before it will dispense the snack (or return your change).

If the vending machine has no notion of states, it would dispense free snacks or change regardless of whether it had received any money. While free snacks might make some hungry people happy, it's not the intended behavior. We would say that the vending machine is broken.

Similar to the working vending machine, in the TCP protocol, a connection cannot be acknowledged (ACK) or data sent (PSH) before the connection has been initiated (SYN). There is a definite order to valid operations, based upon the operation that preceded it. If a connection is not already established—not in a state to receive data—then the receiver will disregard it.

Similar to the broken vending machine, the naked HTTP protocol has no idea what the previous HTTP request was, and therefore no way to predict what the next one might be. Nothing is required to persist from one request to the next. While this was adequate at the time when HTTP was initially designed, when it purely needed to retrieve static text or HTML documents, as the World Wide Web evolved, this was no longer enough. Static pages evolved into dynamic CGI-generated and JavaScripted pages. Dynamic pages use programs to change the page. Scripted pages eventually evolved to fully-fledged multimedia web applications with their own client-server architecture. As pages became software in their own right, a need for sessions arose.

When a web application has its own native authentication, the session may correspond directly with its authentication logs—server-side sessions may start with a login and end with a logout/session timeout. Within each session, there are contexts that the software can use to determine which operations make sense. For example, for each live session, a web application might remember:

Who is the client? What is his/her user name?
Where is the client?
What pages has the client already seen today?
What forms has the client already completed?

However, sessions alone are not enough to ensure that a client’s requested operations make sense. The client’s next page request in the session could break the web application’s logic unless requests are restricted to valid ones.

For example, a web application session may remember that a client has authenticated to it. But unless the web application also knows what pages a client is authorized to use, there might be nothing to prevent a client from accessing unauthorized content.

If a web application doesn't enforce valid state transitions and guard session IDs and cookies from fraud (including side-jacking attacks made famous by Firesheep) or cookie poisoning, web applications become vulnerable to state transition-based attacks—attacks in which pages are requested out of the expected order, by a different client, or where inputs used for the next page are not as expected. While many web applications reflect business logic in order to function, not all applications validate state transitions to enforce application logic. Other web applications do attempt to enforce the software’s logic, but do not do so effectively. In other cases, the state enforcement itself has bugs. These are all common causes of security vulnerabilities.

Similar to plain HTTP, SSL/TLS also keeps track of what steps the client has completed in encryption negotiation, and what the agreed keys and algorithms are. These HTTPS sessions are separate from, and usually in addition to, HTTP sessions. Attacks on SSL/TLS sessions are also possible, such as the SPDY protocol/Deflate compression-related CRIME attack.

FortiWeb sessions vs. web application sessions

FortiWeb can add its own sessions to enforce the logic of your web applications, thereby hardening their security, even without applying patches.

Your web application may have its own sessions data—one or more. These are not the same as FortiWeb sessions, unless FortiWeb is operating in a mode that does not support FortiWeb session cookies, and therefore uses your web application’s own sessions as a cue (see Session Key in Configuring a protection profile for inline topologies).

FortiWeb does not replace or duplicate sessions that may already be implemented in your web applications, such as the JSESSIONID parameter common in Java server pages (JSP), or web applications’ session cookies such as the TWIKISID cookie for Twiki wikis.

However, it can protect those sessions. To configure protection for your web application’s own sessions, see options such as Cookie Security Policy, and Hidden Fields Protection in Configuring a protection profile for inline topologies.

For example, to limit the number of TCP connections of a same user per HTTP session, you can use session cookies to identify the same user. Enable Client Management in inline web protection profile. When enabled and a client sends requests:

For the first HTTP/HTTPS request from a client, FortiWeb embeds a cookie in the response’s Set-Cookie: field in the HTTP header. It is named cookiesession1. (FortiWeb does not use source IP addresses and timestamps alone for sessions: NAT can cloak multiple clients; clocks can be altered.)
Later requests from the same client must include this same cookie in the Cookie: field to be regarded as part of the same session. Otherwise, the request will be regarded as session-initiating, and return to the first step.
Once a request’s session is identified by the session ID in this cookie (e.g. K8BXT3TNYUM710UEGWC8IQBTPX9PRWHB), FortiWeb can perform any configured tracking or enforcement actions that are based upon the requests that it remembers for that session ID, such as rate limiting per session ID per URL (see Limiting the total HTTP request rate from an IP). Violating traffic may be dropped or blocked, depending on your configuration.
After some time, if FortiWeb has not received any more requests, the session will time out.

For the next request from that client, if it contains the old session cookie, the time out period will be For the first HTTP/HTTPS request from a client, FortiWeb embeds a cookie in the response’s Set-Cookie: field in the HTTP header. It is named cookiesession1. (FortiWeb does not use source IP addresses and timestamps alone for sessions: NAT can cloak multiple clients; clocks can be altered.)

Exceptions to this process include network topologies and operation modes that do not support FortiWeb session cookies: instead of adding its own cookie, which is not possible, FortiWeb can instead cue its session states from your web application’s cookie. See Session Key in Configuring a protection profile for inline topologies.

Traffic logs include the HTTP/HTTPS session ID so you can locate all requests in each session. Correlating requests by session ID can be useful for forensic purposes, such as when analyzing an attack from a specific client, or when analyzing web application behavior that occurs during a session so that you can design an appropriate policy to protect it. For details, see Viewing log messages.

Sessions & FortiWeb HA

The table of FortiWeb client session histories is not synchronized between HA members. If a failover occurs, the new active appliance will recognize that old session cookies are from a FortiWeb, and will allow existing FortiWeb sessions to continue. Clients’ existing sessions will not be interrupted.

Because the new active appliance does not know previous session history, after failover, for existing sessions, FortiWeb cannot enforce actions that are based on:

The count or rate of requests that it remembers for that session ID, such as rate limiting per session ID per URL. For details, see Limiting the total HTTP request rate from an IP.

New sessions will be formed with the current main appliance.

For details about what data and settings are synchronized by HA, see HA heartbeat and HA heartbeat & active node election.

Example: Magento & FortiWeb sessions during failover

A client might connect through a FortiWeb HA pair to an e-commerce site. The site runs Magento, which sets cookies in a server pool. To prevent session stealing and other session-based attacks, Magento can track its own cookies and validate session information in $_SESSION using server-side memory.

In the FortiWeb HA pair that protects the server pool, you have enabled Configuring a protection profile for inline topologies so that the active appliance (FortiWeb A) also adds its own cookie to the HTTP response from Magento. The HTTP response therefore contains 2 cookies:

Magento’s session cookie
FortiWeb’s session cookie

The next request from the client echoes both cookies. It is for an authorized URL, so FortiWeb A permits the website to respond.

Let’s say you then update FortiWeb A’s firmware. During the update, the standby appliance (FortiWeb B) briefly assumes the role of the active appliance while FortiWeb A is applying the update and rebooting (e.g., a failover occurs).

After the failover, FortiWeb B would receive the next HTTP request in the session. Because it was previously the standby when the client initiated the session, and FortiWeb session tables are not synchronized, FortiWeb B has no knowledge of the FortiWeb session cookie in this request.

However, a FortiWeb session cookie is present. Therefore FortiWeb B would permit the new request (assuming that it has no policy violations).

Since web application sessions are not the same as FortiWeb sessions, Magento sessions continue and are unaffected by the failover.

If the client deletes their FortiWeb session cookie or it times out, FortiWeb B regards the next request as a new FortiWeb session, adding a new FortiWeb session cookie to Magento’s response and creating an entry in FortiWeb B’s session table.