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.
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 whichpages 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).
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:
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 the specified point. For details, see Specifying URLs allowed to initiate sessions.
- 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.
- 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.)
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 the specified point. For details, see Specifying URLs allowed to initiate sessions..
|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.
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:
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 Session Management 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.
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.