Protection against Man-in-the-Browser (MiTB) attacks
The Man-in-the-Browser (MiTB) attack uses Trojan Horse to intercept and manipulate calls between the browser and its security mechanisms or libraries on-the-fly. The Trojan Horse sniffs or modifies transactions as they are formed on the browser, but still displays back the user's intended transaction. The most common objective of this attack is to cause financial fraud by manipulating transactions of Internet Banking systems, even when other authentication factors are in use.
To protect the user inputs from being attacked by MiTB, FortiWeb implements security rules including:
Obfuscation
To prevent the MiTB attack from identifying the names of the user input field , FortiWeb obfuscates it into meaningless character strings based on Base64 encoding rule.
For example, for the account name, passwords, and other sensitive user input fields on a transaction page, the obfuscation rule is used to disguise the real values of the input field names.
As shown in the following screenshot, the name of the input field "card 1" is displayed as is in the source code of a transaction page.
After the obfuscation rule is applied to the field name "card 1", the real value is disguised as follows. If the Trojan Horse used by the MiTB attack scans this page for user sensitive data, it won't notice this field because the disguised value is meaningless to it.
See the following topics on how to apply obfuscation to protect the names of the user input fields:
Encryption
To protect the password that users enter into the web page, FortiWeb encrypts the password from a readable form to an encoded version based on Base64 encoding rule. The encrypted password can only be decoded by FortiWeb.
The following screenshot shows the password (the "secretkey" parameter) without being encrypted.
If the encryption rule is applied to the "secretkey" parameter, its real value will be encrypted, as shown in the following screenshot:
In this case, even if the MiTB attack extracts user data from this package, the secretkey parameter will be useless to the MiTB attack because the real value is encrypted.
See the following topic on how to apply encryption to protect the password input field:
Anti-Keylogger
Sometimes the MiTB attack installs a key logger on users' browsers and records each key pressed. Sensitive data such as passwords can be intercepted and recorded, compromising the user account.
If the Anti-Keylogger rule is enabled for the password parameter, FortiWeb prevents it from being recorded even if there is a key logger installed on user's browser.
See the following topic on how to apply anti-keylogger to protect the value of the password input field:
AJAX Request allow list
AJAX (Asynchronous JavaScript and XML) requests are a technique used in web development that allows a web page to communicate with a server asynchronously, without requiring a full page reload. This makes web applications more dynamic and interactive, as parts of the page can be updated with new data without disrupting the user's experience. Common use cases of AJAX include:
-
Sending form data to the server without refreshing the page.
-
Loading additional content (e.g., more products in an online store) as the user scrolls down the page.
-
Providing real-time search suggestions as the user types in a search box.
-
Updating a chat window with new messages in real-time.
The MiTB attack may use a malicious AJAX worm to hack into the user's browser. It creates an AJAX based sniffer to override the OPEN and SEND function of the AJAX request, and then send the data to a program on a different domain.
FortiWeb supports configuring an allow list for AJAX requests. If the user's browser sends AJAX requests to an external domain which is not in the allow list, FortiWeb will take action (alert, or alert & deny) according to your configuration.
The following screenshot shows the alert message displayed by FortiWeb when it detects an AJAX request to an external domain not in the allow list.
See the following topic on how to add allow list for the AJAX request:
SSL Stripping Detection
SSL stripping is a form of Man-in-the-Middle (MitM) attack that downgrades HTTPS connections to HTTP, allowing attackers to intercept and manipulate unencrypted traffic. By stripping away encryption, attackers can steal login credentials, inject malicious content, or alter user transactions without detection.
To mitigate SSL stripping attacks, FortiWeb implements security rules that monitor and enforce encrypted connections:
Middle Proxy-Based Detection
FortiWeb introduces a Middle Proxy option in the Man-in-the-Browser (MitB) Protection module, which inspects encrypted traffic and detects SSL stripping attempts. It does this by comparing security attributes between the initial server response and the client-reported data.
-
Example: A server responds with
https://secure.example.com, but the client reportshttp://secure.example.com. FortiWeb detects the protocol downgrade and flags it as a potential SSL stripping attack.
Enforcing HTTP Strict Transport Security (HSTS)
FortiWeb enforces HSTS policies, ensuring that clients always use HTTPS when connecting to protected web applications. This prevents attackers from forcing a downgrade to HTTP.
-
Example: A web application includes the
Strict-Transport-Securityheader in its response, but the client reports a missing HSTS policy. FortiWeb identifies this inconsistency and recommends enabling HSTS enforcement.
Protocol and Security Header Validation
FortiWeb verifies that key security attributes—such as the protocol type, HTTP headers, and User-Agent string—remain consistent throughout the session. Mismatches can indicate SSL stripping in progress.
-
Example: A secure page (
https://login.example.com) redirects a user to another secure page, but the client reports an insecureReferervalue (http://login.example.com). FortiWeb detects this mismatch and raises an alert.
See the following topic on how to apply Middle Proxy to detect SSL stripping: