The HTTP 1.1 protocol itself is stateless (i.e., has no inherent support for persistent sessions). Yet many web applications add sessions to become stateful.
Why?
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:
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:
Because memory is an accumulation of input, sessions have security implications.
When sessions are not protected to prevent misuse, software can be used in unexpected ways by attackers.
For example, let’s say there is a vending machine. You must insert money first. If you:
the machine will do nothing. The machine is designed so that it must be in the state where it has received enough money before it will dispense the snack (or return your change).
If the vending machine had 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 is 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:
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. But unless it also knows what pages that client is authorized to use, there might be nothing to prevent that person from ignoring the links on the current web page and entering a non-authorized URL into their web browser to steal secret information.
If they do not enforce valid state transitions and guard session IDs and cookies from fraud (including sidejacking attacks made famous by Firesheep) or cookie poisoning, web applications become vulnerable to state transition-based attacks — attacks where 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 common causes of security vulnerabilities.
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). FortiWeb does not replace or duplicate sessions that may already be implemented in your web applications, such as the However, it can protect those sessions. To configure protection for your web application’s own sessions, see options such as Cookie Security Policy, Parameter Validation, and Hidden Fields Protection. |
For example, to reinforce authentication logic, you might want to require that a client’s first HTTP request always be a login page. All other web pages should be inaccessible until a client has authenticated, because out-of-order requests could be an attempt to bypass the web application’s authentication mechanism.
How can FortiWeb know if a request is the client’s first HTTP request? If FortiWeb were to treat each request independently, without knowledge of anything previous, it would not be able to remember the authentication request, and therefore could not enforce page order.
To fill this need for context, enable Session Management. When enabled:
1. 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.)
If you have configured rules such as start page rules that are enforced when a page request is the first in a session, FortiWeb can enforce them at this point.
2. 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), or based upon the order of page requests in a session, such as page order rules (see Enforcing page order that follows application logic). Violating traffic may be dropped or blocked, depending on your configuration.
3. After some time, if the FortiWeb has not received any more requests, the session will time out.
The next request from that client, even if it contains the old session cookie, will restart the process at step 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. |
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 and the FortiWeb Log Message Reference.
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:
|
New sessions will be formed with the current main appliance.
For more information on what data and settings are synchronized by HA, see HA heartbeat & synchronization and Configuration settings that are not synchronized by HA.
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 some 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 Session Management, so the active appliance (FortiWeb A) also adds its own cookie to the HTTP response from Magento. The HTTP response therefore contains 2 cookies:
The next request from the client echoes both cookies. It is for an authorized URL, so FortiWeb A permits the web site 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 (i.e. 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.
As a result, it cannot enforce sequence-specific features such as page order, since it does not know the session history. 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, enabling it to enforce page order and start page rules again.
