Fortinet 37 FortiWeb 5.0 Patch 6 Administration Guide
Figure 4: Attack bypassing logical state transitions in a session
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 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.
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.
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.
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 Word).
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 Detection, Parameter Validation, and Hidden
Fields Protection.