Fortinet black logo

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:


Table of Contents

Administration Guide

Enforcing page order that follows application logic

Page order rules (called “page access rules”) define URLs that must be accessed in a specific order to enforce correct business logic or application logic of a web application, and prevent cross-site request forgery (CSRF) attacks.

For example, a password change should always occur in this order:

  1. A client begins an HTTP session by requesting the login page.
    GET /login.asp
  2. When the web server responds, FortiWeb adds its HTTP session cookie to the response to initiate a unique HTTP session for that client. All subsequent requests from the client will include this cookie until the client ends the session or the cookie expires. The cookie identifies the client, and coupled with the request URL, allows FortiWeb to track the client’s current session state, and enforce session-related features.

  3. The client submits his or her authentication credentials.
    POST /checkLogin.asp?account=user1&password=myPassw0rd!
  4. Depending on the web application, the client’s login status could be cached server-side, or could be added to a cookie in the response, to be cached client-side.

  5. If the login is successful, the web application displays the client’s account profile, which includes a password change form.
    GET /profile.asp
  6. The client submits a password change request.
    POST /setPassword.asp?account=user1&password=myPassw0rd!
  7. If the password change is successful, the account profile web page notifies the client.
    GET /profile.asp?status=success

Authentication is required in order to prove the client’s identity. Unless HTTP session initiation is required and initial authentication is bound to that session, an attacker could change (or possibly simply read) the password of any user’s account simply by making a request like The client submits a password change request. POST /setPassword.asp?account=user1&password=myPassw0rd! with the password query in its URL and/or repeating a stolen session cookie. Therefore password access should never be allowed in page requests ordered like this:

  1. An attacker posts a password change for another person’s account.
    POST /setPassword.asp?account=user1&password=myPassw0rd!
  2. The account profile page notifies the attacker of the successful change.
    GET /profile.asp?status=success
    where the password change page (/setPassword.asp) is requested before the client has initiated an authenticated session.

In another example, an e-commerce application might be designed to work properly in this order:

  1. A client begins an HTTP session by adding an item to a shopping cart.
    /addToCart.do
  2. The client either views and adds additional items to the shopping cart at multiple other URLs, or proceeds directly to the checkout.
  3. The client confirms the items to purchase.
    /checkout.do
  4. The client provides shipping information.
    /shipment.do
  5. The client pays for the items and shipment, completing the transaction.
    /payment.do

Sessions that begin at the shipping or payment stage should therefore be invalid. If the web application does not enforce this rule itself, it could be open to CSRF attacks on the payment feature. To prevent such abuse, FortiWeb could enforce the rule itself using a page access rule set with the following order in an HTTP session:

  1. /addToCart.do?item=*
  2. /checkout.do?login=*
  3. /shipment.do
  4. /payment.do

Attempts to request /payment.do before those other URLs (including the first URL, which initiates the HTTP session) during a session would be denied, and generate an alert email and/or attack log message. For details, see Logging and Alert email.

Requests for other, non-ordered URLs are allowed to interleave ordered URLs during the client’s session. (Due to web browsers’ back buttons, flexible and complex features, and customers browsing your e-commerce inventory before completing a transaction, this is common.) Page access rules may be specific to a web host. This ensures that if web applications have URLs with the same name, you do not necessarily have to apply the same page order rules.

You can use SNMP traps to notify you when a page order rule has been enforced. For details, see SNMP traps & queries.

Refer to FortiWeb CLI Reference for how to configure a page access rule and apply it in an inline protection profile.

In order for page access rules to be enforced, you must also enable http-session-management {enable | disable} in waf web-protection-profile inline-protection.

Attack log messages contain Page Access Rule Violation when this feature detects a request for a URL that violates the required sequence of URLs within a session.

Because the new active appliance does not know previous session history, after an HA failover, for existing sessions, FortiWeb will not be able to apply this feature. It will apply to new sessions as they are formed. For details, see Sessions & FortiWeb HA.
See also

Enforcing page order that follows application logic

Page order rules (called “page access rules”) define URLs that must be accessed in a specific order to enforce correct business logic or application logic of a web application, and prevent cross-site request forgery (CSRF) attacks.

For example, a password change should always occur in this order:

  1. A client begins an HTTP session by requesting the login page.
    GET /login.asp
  2. When the web server responds, FortiWeb adds its HTTP session cookie to the response to initiate a unique HTTP session for that client. All subsequent requests from the client will include this cookie until the client ends the session or the cookie expires. The cookie identifies the client, and coupled with the request URL, allows FortiWeb to track the client’s current session state, and enforce session-related features.

  3. The client submits his or her authentication credentials.
    POST /checkLogin.asp?account=user1&password=myPassw0rd!
  4. Depending on the web application, the client’s login status could be cached server-side, or could be added to a cookie in the response, to be cached client-side.

  5. If the login is successful, the web application displays the client’s account profile, which includes a password change form.
    GET /profile.asp
  6. The client submits a password change request.
    POST /setPassword.asp?account=user1&password=myPassw0rd!
  7. If the password change is successful, the account profile web page notifies the client.
    GET /profile.asp?status=success

Authentication is required in order to prove the client’s identity. Unless HTTP session initiation is required and initial authentication is bound to that session, an attacker could change (or possibly simply read) the password of any user’s account simply by making a request like The client submits a password change request. POST /setPassword.asp?account=user1&password=myPassw0rd! with the password query in its URL and/or repeating a stolen session cookie. Therefore password access should never be allowed in page requests ordered like this:

  1. An attacker posts a password change for another person’s account.
    POST /setPassword.asp?account=user1&password=myPassw0rd!
  2. The account profile page notifies the attacker of the successful change.
    GET /profile.asp?status=success
    where the password change page (/setPassword.asp) is requested before the client has initiated an authenticated session.

In another example, an e-commerce application might be designed to work properly in this order:

  1. A client begins an HTTP session by adding an item to a shopping cart.
    /addToCart.do
  2. The client either views and adds additional items to the shopping cart at multiple other URLs, or proceeds directly to the checkout.
  3. The client confirms the items to purchase.
    /checkout.do
  4. The client provides shipping information.
    /shipment.do
  5. The client pays for the items and shipment, completing the transaction.
    /payment.do

Sessions that begin at the shipping or payment stage should therefore be invalid. If the web application does not enforce this rule itself, it could be open to CSRF attacks on the payment feature. To prevent such abuse, FortiWeb could enforce the rule itself using a page access rule set with the following order in an HTTP session:

  1. /addToCart.do?item=*
  2. /checkout.do?login=*
  3. /shipment.do
  4. /payment.do

Attempts to request /payment.do before those other URLs (including the first URL, which initiates the HTTP session) during a session would be denied, and generate an alert email and/or attack log message. For details, see Logging and Alert email.

Requests for other, non-ordered URLs are allowed to interleave ordered URLs during the client’s session. (Due to web browsers’ back buttons, flexible and complex features, and customers browsing your e-commerce inventory before completing a transaction, this is common.) Page access rules may be specific to a web host. This ensures that if web applications have URLs with the same name, you do not necessarily have to apply the same page order rules.

You can use SNMP traps to notify you when a page order rule has been enforced. For details, see SNMP traps & queries.

Refer to FortiWeb CLI Reference for how to configure a page access rule and apply it in an inline protection profile.

In order for page access rules to be enforced, you must also enable http-session-management {enable | disable} in waf web-protection-profile inline-protection.

Attack log messages contain Page Access Rule Violation when this feature detects a request for a URL that violates the required sequence of URLs within a session.

Because the new active appliance does not know previous session history, after an HA failover, for existing sessions, FortiWeb will not be able to apply this feature. It will apply to new sessions as they are formed. For details, see Sessions & FortiWeb HA.
See also