Fortinet FCP - FortiWeb 7.4 Administrator - FCP_FWB_AD-7.4 Practice Questions

Explanation

FortiWeb presents its own certificates only when it must act as a proper TLS endpoint itself – either as a server for administrative access or as a client that needs to authenticate to a backend server with a client certificate. In regular traffic protection, it always uses the real server’s certificate or a policy-defined one, never its own local cert.

Correct Options

✅ B. Making a secondary HTTPS connection to a server where FortiWeb acts as a client
In Reverse Proxy or True Transparent Proxy with “HTTPS to Server” enabled, FortiWeb opens a new TLS session to the backend. When the backend demands mutual authentication, FortiWeb sends its own uploaded local certificate as the client certificate to satisfy the server’s requirement.

✅ D. An administrator session connecting to the GUI using HTTPS
Every time an admin opens the FortiWeb web interface over HTTPS, FortiWeb functions as the TLS server. It serves the certificate configured under System > Certificates > Local Cert (or the default self-signed one) to encrypt the management session securely.

Incorrect Options

❌ A. Connecting to browser clients using SSL
For normal user traffic, FortiWeb never presents its own certificate to browsers. It either passes or re-signs the real backend server’s certificate (using SNI or the certificate defined in the server policy) so clients see the legitimate site certificate, not FortiWeb’s.

❌ C. Routing an HTTPS connection to a FortiGate
When FortiWeb redirects or forwards traffic to a FortiGate (e.g., via ICAP, redirection rules, or integration), it does not terminate TLS itself in a way that requires its own certificate. The original client TLS session either stays intact or is handled by FortiGate directly.

Summary
FortiWeb uses its own certificates only for GUI management access and when it must present a client certificate to a backend server during re-encryption. It never uses its own cert for regular client-facing traffic or when simply routing connections to another device.

Reference
Fortinet FortiWeb 7.4.0 Administration Guide
System > Certificates > Local Certificates
System > Admin > Settings → HTTPS certificate selection
Server Policy → HTTPS to Server → Client Certificate options

Explanation:

A Cross-Site Scripting (XSS) attack occurs when an attacker injects malicious, client-side scripts into a trusted website. This script then executes in the victim's browser, allowing the attacker to steal cookies, session tokens, or other sensitive information. It exploits the trust a user has for a particular site.

Correct Option:

🟢 B. < img src = " http://badfile/nothere " onerror = " alert(document.cookie) ; " >
This is a correct and classic example of an XSS payload. It uses an HTML tag with a deliberately invalid source. When the image fails to load, it triggers the onerror event, which executes the malicious JavaScript (alert(document.cookie)). This demonstrates how an attacker can run scripts to access a user's browser data.

Incorrect Options:

🔴 A. SELECT username FROM accounts WHERE username='admin';-- ' AND password='password';
This is an example of a SQL Injection attack, not XSS. The -- sequence is an SQL comment that causes the database to ignore the subsequent password check, allowing unauthorized login. This attacks the database server, not the client's browser.

🔴 C. SELECT username FROM accounts WHERE username='XSS' ' AND password='alert("http://badurl.com")';
This is another SQL Injection example. It attempts to break the SQL query structure by closing the username field early. Although it contains the text "alert," it is embedded within a database query string and is not executable script in a browser context.

🔴 D. < img src = " xss.png " >
This is a normal, harmless HTML image tag. It contains no malicious attributes (like onerror, onload, etc.) and does not attempt to execute any script. Therefore, it does not represent an XSS attack vector.

Summary:
Option B is the correct example of XSS, using a malicious script in an HTML event handler. Options A and C are SQL injection attacks targeting a database. Option D is benign HTML with no malicious intent.

Reference:
For details on how FortiWeb identifies and mitigates such attacks using signatures and policies, please consult the official FortiWeb Administration Guide from the Fortinet Documentation Library.

Explanation

✅ Correct Options:

✅ A. You should run the vulnerability scan during a maintenance window.
Running vulnerability scans consumes system resources and can cause interruptions. Scheduling scans during a maintenance window minimizes disruption to users while allowing a thorough security assessment. This approach follows best practices and helps maintain business continuity.

✅ C. You should run the vulnerability scan in a test environment.
Scanning in a test environment prevents accidental downtime on production systems. It allows administrators to verify scan configurations, detect false positives, and adjust parameters safely before applying them to live systems. This practice reduces risk while maintaining effective vulnerability management.

❌ Incorrect Options:

❌ B. You should run the vulnerability scan multiple times so it can automatically update the scan parameters.
Vulnerability scans do not automatically update scanning rules or parameters. Repeating scans without updating definitions may miss new threats or produce outdated results. Administrators must manually update the scanner to ensure accurate detection.

❌ D. You should run the vulnerability scan on the live website to get accurate results.
Scanning a live website can disrupt services and cause downtime. Accurate results can be achieved in controlled environments, and if live scans are necessary, they should be run cautiously during maintenance windows.

Summary:
Vulnerability scans should be conducted in safe, controlled settings—like test environments or maintenance windows—to avoid disruptions. Simply repeating scans or scanning live sites without preparation can be risky or ineffective. Proper planning ensures both accuracy and safety.

Reference:
Vulnerability scans

Explanation

The accurate statement about the potential attack shown in the exhibit is D.

✅ Correct Option: D
192.168.1.11 is sending suspicious traffic to FortiWeb.
The "Web Page Blocked!" status, along with the Client IP of 192.168.1.11, confirms FortiWeb detected the traffic from this source as a threat. The Attack ID 20000010 identifies the action as a credential-breach attempt. FortiWeb's action of generating this block page proves that it is actively stopping the hostile traffic originating from the client to protect the backend web server.

❌ Incorrect Option: A
The attacker has successfully retrieved the credentials to www.example.com.
The display of a "Web Page Blocked!" status is a security notification confirming FortiWeb has successfully intercepted and stopped the malicious traffic before it reached the server. Since the brute force attempt was blocked by the WAF, the attacker was highly likely unsuccessful in obtaining credentials. A successful attack would typically result in a normal application response, bypassing the security alert.

❌ Incorrect Option: B
www.example.com is running attacks against the client 192.168.1.11.
This statement reverses the attack flow. FortiWeb, as a WAF, is specifically deployed to protect the server (www.example.com) from attacks launched by external clients. The Client IP 192.168.1.11 is clearly the origin of the blocked traffic, making it the source of the aggression. The WAF's intended purpose is entirely defensive, protecting the web application.

❌ Incorrect Option: C
The attack has happened 10 times.
The Attack ID, 20000010, is a permanent, static identifier. The trailing digits (0010) are part of the signature label referencing the security rule for "Brute Force Logins." The number 10 is an identification element, not a dynamic counter of attack occurrences. The actual frequency is tracked in the FortiWeb system logs, but the Attack ID itself is a fixed label for the threat category.

📄 Summary
This response confirms that the FortiWeb block page correctly identifies the client IP 192.168.1.11 as the source of suspicious brute force login traffic. FortiWeb successfully intercepted this traffic, protecting the targeted web application from the attack.

🔗 Reference
For official documentation on interpreting FortiWeb log messages and attack IDs, consult the FortiWeb Administration Guide available on the Fortinet official document library website.

Explanation

In SAML (Security Assertion Markup Language), authentication is strictly separated: the Identity Provider (IdP) is the only component that stores and verifies user credentials (username and password). The Service Provider (SP), such as FortiWeb in SP mode, never sees or stores passwords – it simply trusts assertions issued by the IdP after successful authentication.

Correct Option

✅ A. Identity provider
The Identity Provider (IdP), such as FortiAuthenticator, Azure AD, Okta, or ADFS, is the trusted entity that maintains the user directory and credential database. When a user logs in, the IdP directly receives and validates the username and password, then issues a signed SAML assertion to the Service Provider (FortiWeb) confirming successful authentication.

Incorrect Options

❌ B. Service provider
The Service Provider (FortiWeb when configured as SAML SP) never receives or stores user passwords in SAML flows. It only consumes the SAML assertion sent by the IdP and grants access based on attributes inside that assertion.

❌ C. User database
“User database” is not a standard SAML component or role. While the IdP relies on an underlying directory (LDAP, local DB, etc.), the SAML specification defines the role as “Identity Provider,” not a generic database.

❌ D. Authentication client
There is no role called “authentication client” in SAML architecture. The user’s browser acts as the User Agent that redirects between IdP and SP, but it never stores or validates credentials itself.

Summary
Only the Identity Provider (IdP) stores and verifies user credentials in a SAML deployment.
FortiWeb acting as Service Provider trusts the IdP and never handles passwords directly.
This separation is the core security principle of federated SAML authentication.

Reference
Fortinet FortiWeb 7.4.0 Administration Guide
→ User Authentication > SAML Authentication
→ FortiWeb as SAML Service Provider (SP) configuration

Explanation:

The exhibit shows that Signature ID 010000001, which detects mousedown-based XSS attempts, includes a signature exception for the exact URL http://my.blog.org/user1/blog.php. In FortiWeb, a signature exception tells the system to skip applying that signature whenever the request matches the configured URL. Because the attack is sent to a URL that is explicitly exempted, FortiWeb will not inspect or block it. The request therefore passes through normally.

Correct Option: ✅ D. The connection will be allowed.
Signature exceptions override signature enforcement. When the request URL matches an exception entry, FortiWeb does not evaluate the signature at all. No detection, no sanitization, and no blocking occur. Since the mousedown XSS attempt is aimed at a URL listed under the signature exception, the system allows the connection without inspection.

Incorrect Options:

❌ A. The connection will be stripped of the mousedown JavaScript code.
FortiWeb does not remove or sanitize malicious JavaScript when a signature exception exists. Instead, it bypasses inspection entirely for that signature. Because the signature is skipped, FortiWeb does not modify the request, meaning nothing is stripped or cleaned from the attack payload.

❌ B. The connection will be blocked as an XSS attack.
Blocking would only occur if the signature were applied. However, the exception prevents this signature from being evaluated for the specified URL. This means the XSS detection logic never triggers, so the system cannot block the request. The attack simply passes through untouched.

❌ C. FortiWeb will report the new mousedown attack to FortiGuard.
Reporting requires detection. Since the exception prevents the signature from running, FortiWeb never identifies the request as malicious. Without detection, nothing is logged or forwarded to FortiGuard. Exception rules stop both inspection and reporting for the matched request.

Summary:
Because the request targets a URL listed under a signature exception, FortiWeb bypasses the mousedown XSS signature. The system neither analyzes nor blocks the attack. As a result, the connection is fully allowed despite containing the XSS payload.

Reference:
Configuring action overrides or exceptions to data leak & attack detection signatures

Explanation

Correct Option: 🟢 B. Active-Passive

This HA mode relies on Gratuitous ARP (GARP). In an Active-Passive cluster, only one unit actively handles traffic. When a failover occurs and the passive unit becomes active, it immediately broadcasts GARP packets. These packets advertise that the shared virtual IP address is now associated with its physical MAC address. This forces all neighboring switches and hosts to update their ARP caches instantly, rerouting traffic to the new active device within seconds and minimizing service interruption.

Incorrect Options:

🔴 A. Passive-Passive:
This is not a recognized or standard HA configuration. In a functional HA setup, at least one device must be active to process traffic. A "Passive-Passive" state would mean no device is handling network traffic, which contradicts the purpose of high availability.

🔴 C. Active-Active:
In this mode, both devices are active and typically share the traffic load. Failover mechanisms are different; they often use a master/primary election and session synchronization. While GARP might be used in some implementations, the primary method for redirecting traffic is not a simple L2 broadcast but is more commonly managed through routing protocols or load balancers.

🔴 D. Passive-Active:
This is simply an incorrect ordering of the standard term "Active-Passive." The naming convention for HA modes always states the role of the traffic-processing unit first ("Active"), followed by the standby role ("Passive").

Summary:
The Active-Passive high availability mode is specifically designed to use Gratuitous ARP as its core mechanism to notify the local network segment of a failover event. This ensures a rapid and transparent transition. The other options either do not exist as standard modes or represent architectures that do not depend on GARP for primary failover communication.

Reference:
The use of GARP for failover notification in an Active-Passive HA pair is a standard networking principle and is documented in vendor-specific implementation guides, such as the FortiWeb Administration Guide for Fortinet's web application firewalls.