Key concepts : HTTP sessions & security : FortiWeb sessions vs. web application sessions
 
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 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 Poisoning, 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 step 1.)
Figure 5: Attack blocked via a start page or page order rule with session management
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, or based upon the order of page requests in a session, such as page order rules. 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 1.
 
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.