Enforcing page order that follows application logic
Page order rules (called “page access rules” in the web UI) 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:
- A client begins an HTTP session by requesting the login page.
GET /login.asp - The client submits his or her authentication credentials.
POST /checkLogin.asp?account=user1&password=myPassw0rd! - If the login is successful, the web application displays the client’s account profile, which includes a password change form.
GET /profile.asp
-
The client submits a password change request.
POST /setPassword.asp?account=user1&password=myPassw0rd! - If the password change is successful, the account profile web page notifies the client.
GET /profile.asp?status=success
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.
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.
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:
- An attacker posts a password change for another person’s account.
POST /setPassword.asp?account=user1&password=myPassw0rd!
- 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:
- A client begins an HTTP session by adding an item to a shopping cart.
/addToCart.do
- The client either views and adds additional items to the shopping cart at multiple other URLs, or proceeds directly to the checkout.
- The client confirms the items to purchase.
/checkout.do
- The client provides shipping information.
/shipment.do - 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:
-
/addToCart.do?item=* -
/checkout.do?login=* -
/shipment.do -
/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.
To configure a page order rule
- Before you configure a page order rule, if you want to apply it only to HTTP requests for a specific real or virtual host, you must first define the web host in a protected host names group. For details, see Defining your protected/allowed HTTP “Host:” header names.
- Go to Web Protection > Access > Page Access.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions. - Click Create New.
- Configure these settings:
- Informative
- Low
- Medium
- High
- Click OK.
- Click Create New to add an entry to the set.
- Configure these settings:
- the literal URL, such as
/cart.php, that the HTTP request must contain in order to match the page access rule. The URL must begin with a slash ( / ). - a regular expression, such as
^/*.php, matching all and only the URLs to which the page access rule should apply. The pattern does not require a slash ( / ); however, it must at match URLs that begin with a slash, such as/cart.cfm. - Click OK.
- Repeat the previous steps for each individual rule that you want to add to page access.
- To apply an access rule:
- Select it in an inline protection profile. For details, see Configuring a protection profile for inline topologies.
- Enable Session Management.
Attack log messages contain
Page Access Rule Violationwhen 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.
|
Name |
Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters. |
|
Severity |
When rule violations are recorded in the attack log, each log message contains a Severity Level ( The default value is Medium. |
|
Trigger Policy |
Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Viewing log messages. |
| ID |
Type the index number of the individual rule within the page access rule, or keep the field’s default value of Page access rules should be added to the set in the order which clients will be permitted to access them. For example, if a client must access |
| Host |
Select the name of a protected host that the This option is available only if Host Status is enabled. |
| Host Status | Enable if you want the page access rule to apply only to HTTP requests for a specific web host. Also configure Host. |
| Type | Indicate whether URL Pattern is a Simple String (that is, a literal URL) or a Regular Expression. |
| URL Pattern |
Depending on your selection in Type, enter either: Do not include the domain name, such as To create and test a regular expression, click the >> (test) icon. This opens the Regular Expression Validator window where you can fine-tune the expression. For details, see Regular expression syntax. |