Web Application and API Security

Lab Guide
FFT-WEB-r04-1746804374
Table of contents
1. Web application and API Security ............................................................................................. 4
1.1. FastTrack Program ............................................................................................................ 5
1.2. Agenda ................................................................................................................................ 6
1.3. Topology .............................................................................................................................. 7
2. Initial Configuration ..................................................................................................................... 8
2.1. Perform Initial Configuration ........................................................................................... 9
2.2. Verify Network Communications ................................................................................... 11
2.3. Create a Signature .......................................................................................................... 13
2.4. Create a Web Protection Profile .................................................................................... 14
2.5. Configure Server Policy .................................................................................................. 16
3. Configure Local/Remote Logging & Sensitive Data Masking .............................................. 17
3.1. Initialization ...................................................................................................................... 18
3.2. Configure Local Logging ................................................................................................. 19
3.3. Test Local Logging .......................................................................................................... 21
3.4. Secure Local Logging by Masking Sensitive Data ...................................................... 23
3.5. Test Sensitive Data Masking ......................................................................................... 25
3.6. FortiAnalyzer Logging ..................................................................................................... 26
4. Credential stuffing, User Tracking and Authentication ....................................................... 28
4.1. Initialization ...................................................................................................................... 29
4.2. Credential Stuffing .......................................................................................................... 30
4.3. Test Credential Stuffing Defense .................................................................................. 33
4.4. Enable User Tracking ...................................................................................................... 34
4.5. Test User Tracking ........................................................................................................... 36
4.6. Enable HTTP Authentication .......................................................................................... 37
4.7. Test HTTP Authentication .............................................................................................. 42
5. Implement Certificates and Encryption .................................................................................. 43
5.1. Initialization ...................................................................................................................... 44
5.2. Uploading a Server Certificate and Private Key ......................................................... 45
5.3. Implementing HTTPS Offloading ................................................................................... 48
5.4. Rewriting and Redirecting HTTP to HTTPS .................................................................. 50
6. Protect Against Zero-Day Attacks Using Machine Learning ............................................... 51
6.1. Initialization ...................................................................................................................... 52
6.2. Configuring Machine Learning Anomaly Detection .................................................... 53
6.3. Establishing The Model ................................................................................................... 57
6.4. Protecting and Adapting ................................................................................................ 60
7. Known Bot Mitigation ................................................................................................................ 62
7.1. Initialization ...................................................................................................................... 63
7.2. Known Bot Test ................................................................................................................ 64
7.3. Known Bot Protection ..................................................................................................... 65
7.4. Test Known Bot Protection. ........................................................................................... 66
8. Injection ....................................................................................................................................... 67
8.1. Initialization ...................................................................................................................... 68
8.2. SQLi Attack and FortiWeb Protection .......................................................................... 69
8.3. XSS Attack and FortiWeb Protection ............................................................................ 72
9. Securing Your Cookie ................................................................................................................ 75
9.1. Initialization ...................................................................................................................... 76

Web Application and API Security Lab Guide

Page 2 of 85 Fortinet Training Institute
 9.2. Protection For Cookie without HttpOnly ...................................................................... 77
9.3. Test Protection for Cookie without HttpOnly .............................................................. 80
9.4. Protection For Cookie without Secure attribute ........................................................ 81
9.5. Test Protection For Cookie without Secure attribute ................................................ 82
10. Conclusion ................................................................................................................................. 84
10.1. Continued Education ..................................................................................................... 85

Web Application and API Security Lab Guide

Page 3 of 85 Fortinet Training Institute
1. Web application and API Security

Fast Track Workshop: Web Application and API Security

In this hands-on workshop, you explore the features and capabilities that FortiWeb offers to help you protect your web
application, achieve PCI DSS compliance, and OWASP Top10 mitigation within your network.

To do this, you examine, and implement a selection of the following features:

• Initial configuration of FortiWeb

• Local logging, sensitive data masking, and FortiAnalyzer remote logging (optional)

• Credential Stuffing, user tracking and authentication (optional)

• SSL/TLS, including HTTPS offloading and redirection (optional)

• Machine learning (optional)

• Bot Mitigation (optional)

• Injection (optional)

• Secure Your Cookie (optional)

Many of these activities can be done as independent tasks. The duration of this workshop is insufficient for you to complete
all of the above activities, so you should focus on those topics that are of the greatest interest to you. If time remains, you
may also have the opportunity to attempt others.

Tasks

The blue button at the top of this page is the primary action button. When an action can be completed on the page, this
button will change accordingly.

When ready, click the blue Continue button in the menu at the top of the page to get started.

Web Application and API Security Lab Guide

Page 4 of 85 Fortinet Training Institute
1.1. FastTrack Program

FAST TRACKS are free instructor-led hands-on workshops that introduce Fortinet solutions for securing your digital
infrastructure. These workshops are only an introduction to what Fortinet security solutions can do for your organization.

For more in-depth training, we encourage you to investigate our full portfolio of NSE training courses at
https://training.fortinet.com.

Web Application and API Security Lab Guide

Page 5 of 85 Fortinet Training Institute
1.2. Agenda

Agenda

This lab consists of two sections: core and optional. You must complete all exercises in the core section before the optional
section becomes available.

Core

The core section of this lab contains the following exercises.

Section Title Duration Prerequisite

2 Initial Configuration 15 Minutes -

Optional

The optional section of this lab contains the following exercises.

3 Configure Local/Remote 20 Minutes 2

Logging & Sensitive Data
Masking
4 Credential Stuffing, User 25 Minutes 2
Tracking and
Authentication
5 Implement Certificates 30 Minutes 2
and Encryption
6 Protect Against Zero-Day 45 Minutes 2
Attacks Using Machine
Learning
7 Known Bot Mitigation 15 Minutes 2
8 Injection 30 Minutes 2
9 Secure Your Cookie 30 Minutes 2

Tasks

Click Continue to move to the next page.

Web Application and API Security Lab Guide

Page 6 of 85 Fortinet Training Institute
1.3. Topology

Topology

Below is the topology you use in the exercises to demonstrate FortiWeb functionality. It includes FortiWeb in the DMZ, as
well as a web server in a data center. Traffic flow is from the Kali Linux to the FortiWeb, to the web server, and back.

The FortiGate-Edge device is configured with a Virtual IP of 100.65.0.124 on the Internet-facing port, which is then mapped
to the FortiWeb’s Port 2 address of 172.16.99.124

Unless otherwise indicated, all passwords are Fortinet1!

Tasks

Click Continue to move to the next page.

This will be the last time we specifically state to click on the Continue button, from now on it is assumed that the user
understands how to move forward.

Web Application and API Security Lab Guide

Page 7 of 85 Fortinet Training Institute
2. Initial Configuration
Initial Configuration

The first step in using FortiWeb to help achieve application protection is to deploy your FortiWeb device and perform some
basic configuration.
For this Fast Track, your FortiWeb has already been configured for management access via the GUI. You must still configure
the basic elements of the configuration to allow FortiWeb to communicate with, and protect, your web application.

After you defined the basic connectivity between your FortiWeb and the back-end web application. To protect the web
application, you create a protection profile, which you assign to the server policy. FortiWeb requires three basic elements: a
signature (or rule), a profile, and a policy.

You should always begin by building the signature first, then the profile, and then link them together in the policy.

Objectives

In this exercise, you do the following:

• Configure a virtual server

• Configure a server pool

• Configure a server policy

• Test network connectivity

• Create a basic signature and a basic web protection profile.

• Add protection profile to server policy

Time to Complete:
Estimated: 15 minutes

Web Application and API Security Lab Guide

Page 8 of 85 Fortinet Training Institute
2.1. Perform Initial Configuration

Background

When configuring FortiWeb, there are several linked elements that you must configure in a specific order. The basic
sequence is to build a rule, link the rule to a profile, and then link the profile to a policy. The policy governs all aspects of
traffic flow between FortiWeb and the web application/server.

In this exercise, you create a Server Policy to protect the Web Application. To create the Server Policy, you first need to
create two Server objects: a virtual server, which represents the service IP address that the clients will be connecting to, and
a server pool, which represents the IP address of the actual web server that FortiWeb protects.

Tasks

Create a Virtual Server

1. From the Lab Activity: FortiWeb sidebar menu, access FortiWeb using the HTTPS option.

2. Log in using the username admin and the password Fortinet1!

3. Click Server Objects > Server > Virtual Server

4. Edit vServer_ACMECORP

5. Click Create New

6. Turn on Use Interface IP

7. Set Interface to port2

8. Click Ok

Create the Server Pool

1. Click Server Objects > Server > Server Pool

2. Edit ServerPool_ACMECORP

Web Application and API Security Lab Guide

Page 9 of 85 Fortinet Training Institute
3. Click Create New to create a new server pool rule

4. Set IP to the web server’s IP Address 172.16.100.58.

5. Leave the default values and click OK

Create the Server Policy

1. Click Policy > Server Policy

2. Click Create New and set the name to ServerPolicy_ACMECORP

3. Set Virtual Server to vServer_ACMECORP

4. Set Server Pool to ServerPool_ACMECORP

5. Set HTTP Service to HTTP

6. Click OK

Web Application and API Security Lab Guide

Page 10 of 85 Fortinet Training Institute
2.2. Verify Network Communications

Background

Now that you have configured a server policy, your clients should be able to connect to the back-end web application. In this
exercise, you will verify that the Kali Linux client can reach the ACMECORP website.

Before you configure any of FortiWeb’s protection features, you should make sure you can connect to the Web Application
via FortiWeb working in reverse proxy mode with the Server Policy that you just created.

Tasks

1. From the Lab Activity: FortiWeb sidebar menu, access Kali using the RDP option.

2. Click Start.

3. Launch Mozilla Firefox, and click on the AcmeCorp Login bookmark

4. The AcmeCorp login page opens

NOTE: If you are not able to access the login page, check your configuration before continuing.

Question

Which of the FortiWeb configuration element identifies the IP Address that clients will use to access your web application?

Select the correct answer(s)

Virtual server

Web Application and API Security Lab Guide

Page 11 of 85 Fortinet Training Institute
 Server pool

Server policy

Server Pool Rule

Web Application and API Security Lab Guide

Page 12 of 85 Fortinet Training Institute
2.3. Create a Signature

Background

In this exercise, you will manually create a basic signature.

While FortiWeb has predefined signatures for many common web applications, such as Drupal and WordPress, you cannot
directly modify these for use with custom applications, such as ones built in-house by your business unit or IT department.
To protect those custom applications, you need to create a custom signature. There are three ways you can accomplish this:

Find a prebuilt signature that is close to your needs, clone it, and modify it

Use the signature wizard to build a basic signature and modify it

Create a signature manually

Tasks

1. On FortiWeb. Click Web Protection > Known Attacks > Signatures.

2. Click Create New.

3. Set the Name to signature1 and leave all other settings at the default value.

4. Click OK.

5. The new signature appears in the list of signatures.

Web Application and API Security Lab Guide

Page 13 of 85 Fortinet Training Institute
2.4. Create a Web Protection Profile

Background

In this exercise, you create a web protection profile that will utilize the signature you created in the previous activity.

Inline protection profiles combine previously configured rules, profiles, and policies into a comprehensive set that can be
applied by a policy. Inline protection profiles contain only the features that are supported in inline topologies, which you use
with operation modes such as Reverse Proxy and True Transparent Proxy.

Tasks

1. Click Policy > Web Protection Profile.

2. Click Create New.

3. Set the Name to protection1.

4. Verify that Client Management is on. This adds a cookie to the reply for FortiWeb to track the state of web applications
across multiple requests

5. From the Signatures drop-down list, select signature1

6. In the IP Protection section, ensure IP Reputation is turned on. This ensures that FortiWeb uses a blacklist, supplied by
FortiGuard, to protect your network from known malicious source IP addresses.

7. Click OK.

8. You should now see the new protection profile

Web Application and API Security Lab Guide

Page 14 of 85 Fortinet Training Institute
 Web Application and API Security Lab Guide
Page 15 of 85 Fortinet Training Institute
2.5. Configure Server Policy

Background

Now that you have created a signature, and linked it to a protection profile, you need to assign it to the server policy. This is
how you define what protections and rules FortiWeb will apply to each server pool.

In this exercise, you modify the server policy that you created during the initial setup.

Tasks

1. Click Policy > Server Policy.

2. Click ServerPolicy_ACMECORP.

3. Click Edit.

4. In the Security Configuration section, use the Web Protection Profile drop-down list to select protection1.

5. Click Ok.

Web Application and API Security Lab Guide

Page 16 of 85 Fortinet Training Institute
3. Configure Local/Remote Logging & Sensitive Data Masking
Background

In this lab, you configure local logging on the FortiWeb and secure stored data with sensitive data masking.
Both logging and sensitive data masking are key requirements for PCI DSS compliance. Logging is considered critical for
forensic purposes in the event of a breach, and masking of sensitive data is critical to reduce the risk of this data being seen
or used by unauthorized individuals.

External logging to something like a FortiAnalyzer or FortiSIEM is strongly recommended and part of the OWASP Top 10
requirement, you will go through FortiAnalyzer integration with FortiWeb, viewing FortiWeb reports and logs on
FortiAnalyzer.

Objectives

• Configure and test local logging

• Implement and test sensitive data masking

• FortiAnalyzer logging

Time to Complete:
Estimated: 20 minutes

Web Application and API Security Lab Guide

Page 17 of 85 Fortinet Training Institute
3.1. Initialization

Initial Configuration for this Lab

To complete this objective, the FortiWeb must be preconfigured correctly.

Clicking Continue will perform a configuration restore on the FortiWeb.

This will cause the FortiWeb to reboot.

Communications with the FortiWeb will be briefly interrupted while the restore process completes.

Web Application and API Security Lab Guide

Page 18 of 85 Fortinet Training Institute
3.2. Configure Local Logging

Background

In this exercise, you will configure and implement local logging. You will then generate traffic and attacks to generate log
entries. Lastly, you will review and verify the collected log data.
For this exercise, you will utilize some settings that are not typically recommended for day-to-day use in a live deployment.
These settings would generate an excessive volume of log data, resulting in increased disk usage, and CPU cycles. These
settings are being used here for demonstration purposes only

Before you configure FortiWeb to send logs to centralized storage, enable local logging and verify that expected events are
being recorded.

Tasks

Review the Global Log Settings

1. On FortiWeb, Click Log&Report > Log Config > Global Log Settings.

2. Verify that the Disk is turned on and the Log Level is set to Information.

Enable Other Log Settings

1. Click Log&Report > Log Config > Other Log Settings.

2. Turn on Custom Access Violation.

3. Click Apply.

4. Click CLI Console on the top right corner.

5. To enable the traffic log configure the following commands.

FortiWeb# config server-policy policy

FortiWeb(policy)# edit ServerPolicy_ACMECORP

FortiWeb(ServerPolicy_A~M)# set tlog enable

FortiWeb(ServerPolicy_A~M)# end

FortiWeb# config log traffic-log

Web Application and API Security Lab Guide

Page 19 of 85 Fortinet Training Institute
 FortiWeb(traffic-log)# set status enable

FortiWeb(traffic-log)# set packet-log enable

FortiWeb(traffic-log)# end

Web Application and API Security Lab Guide

Page 20 of 85 Fortinet Training Institute
3.3. Test Local Logging

Tasks

1. Click Log&Report > Log Access > Event. You can view many events, such as:

Login attempts

Periods when the web servers are unreachable by the server health monitors

Attack simulations, in the attack log

Attempts to connect through the virtual server, in the traffic log, even if the attempt was blocked. In cases where the
attempt was blocked, there will be a request, but no corresponding response from the server.

2. On Kali. Click the Credit Card Input bookmark.

3. The fields are already populated. Click Submit Details.

4. Return to the FortiWeb browser tab.

5. Click Log&Report > Log Access > Traffic.

6. Locate the log entry for the credit card transaction. It should be the topmost entry and list post in the Method column.

7. Double-click the log entry to access the details

In the Raw Body section, you can see the full details of the credit card data entry, including name, card number, and so
on. Storing cardholder data in this manner, even in the local logs, is a direct breach of PCI DSS requirements.

Web Application and API Security Lab Guide

Page 21 of 85 Fortinet Training Institute
 Web Application and API Security Lab Guide
Page 22 of 85 Fortinet Training Institute
3.4. Secure Local Logging by Masking Sensitive Data

Background

One of the many PCI DSS compliance requirements is the masking of sensitive data stored in logs. As you saw in the
previous activity, by default, FortiWeb local logs store data in plain text.

FortiWeb provides predefined rules that can be applied in most cases, however, in some cases, you may need to use custom
rules. Since the web application used in this lab is a custom application, built in-house, the sensitive fields do not necessarily
follow the conventions expected by the prebuilt rules. As a result, you will build a few custom rules to mask credit card
numbers and CVV values.

Tasks

Mask Sensitive Data

1. Click Log&Report > Log Config > Sensitive Data Logging.

2. Turn on both Enable Predefined Rules and Enable Custom Rules.

3. Click Create New to create a custom rule.

4. Set Name to CardNumber.

5. Select Field Mask.

6. Set the Field Name to number. This must match the field value name in the web application. This identifies which field
the rule applies to, in this case, the actual card number.

7. Set the Field Value to the regular expression (regex) \d{16}

\d indicates that the rule should replace a numerical digit, and {16} indicates that it should replace 16 consecutive digits
(the normal length of most credit card numbers).

Web Application and API Security Lab Guide

Page 23 of 85 Fortinet Training Institute
 8. Click OK.

9. Click Create New to add another custom rule.

10. Set Name to cvv.

11. Select Field Mask.

12. Set the Field Name to cvv. This rule applies to the card verification value number.

13. Set Field Value to \d{3}

\d indicates that the rule should replace a numerical digit, and {3} indicates that it should replace 3 consecutive digits
(normal length of Card Verification Value numbers)

14. Click Ok

15. View the two new custom rules.

16. Go to Log&Report > Log Access > Traffic.

17. Locate the traffic log from the previous credit card activity. Double-click the log entry to access the details

18. In the Raw Body section, you can still see the full details of the credit card data entry, because sensitive data logging
rules do not apply retroactively. Only new log entries will be masked by the new rules.

Web Application and API Security Lab Guide

Page 24 of 85 Fortinet Training Institute
3.5. Test Sensitive Data Masking

Tasks

1. On Kali, launch Mozilla Firefox, and click the Credit Card Input browser bookmark.

2. Click Submit Details.

Review the Logs

1. On FortiWeb, click Log&Report > Log Access > Traffic.

2. Locate the most recent post log entry.

3. Double-click the log entry to access the details.

4. In the Raw Body section, both the number field and the cvv field are masked.

Web Application and API Security Lab Guide

Page 25 of 85 Fortinet Training Institute
3.6. FortiAnalyzer Logging

Background

It’s important to have data logging on local storage as well as sending data to remote storage as recommended by the
OWASP Top10. In the lab, you will be viewing the FortiWeb integration with FAZ, and viewing the logs and weekly reports on
FAZ.

Tasks

FortiWeb remote logging to FortiAnalyzer

1. On FortiWeb, click Log&Report > Log Access > Attack to view attack logs.

2. Click Log&Report > Log Policy > FortiAnalyzer Policy.

3. Double-click FortiAnalyzer to view it.

4. Click Log&Report > Log Policy > Trigger Policy

5. Double-click the FortiAnalyzer Trigger to view it.

6. Click Log&Report > Log Config > Global Log Settings to view settings.

Web Application and API Security Lab Guide

Page 26 of 85 Fortinet Training Institute
View Reports and FortiAnalyzer

1. From the Lab Activity: FortiWeb sidebar menu, access FortiAnalyzer using the HTTPS option using the following
credentials
Username: admin Password: Fortinet1!

2. Click on Reports > Report Definitions > All Reports

3. Search for Fortiweb using the search on the top right corner, then select FortiWeb Default Report.

4. Click Run Report.

5. Click Generated Reports.

6. Click HTML to view the report on a new browser page.

7. Click on the Reports in the top left corner and browse to Log View

8. Expand the FortiWeb tab to view different logs (Attack, Event, and Traffic)

Web Application and API Security Lab Guide

Page 27 of 85 Fortinet Training Institute
4. Credential stuffing, User Tracking and Authentication
Authentication and User Tracking

In this lab, you use FortiWeb advanced protection to track users connecting to a website, enable credential stuffing defense
and enforce authentication to specific hostnames. Before you provide a login form to users, it is a best practice to:

• Limit access to plausible source IP addresses, URLs, rates, and so on

• Apply SSL/TLS to encrypt the channel when usernames and passwords are transmitted

Objectives

• Track sessions by user

• Credential stuffing defense

• Apply web authentication using hostnames

Time to Complete:
Estimated: 25 minutes

Web Application and API Security Lab Guide

Page 28 of 85 Fortinet Training Institute
4.1. Initialization

Initial Configuration for this Lab

To complete this objective, the FortiWeb must be preconfigured correctly.

Clicking Continue will perform a configuration restore on the FortiWeb.

This will cause the FortiWeb to reboot.

Communications with the FortiWeb will be briefly interrupted while the restore process completes.

Web Application and API Security Lab Guide

Page 29 of 85 Fortinet Training Institute
4.2. Credential Stuffing

Background

Attackers have easy access to millions of unique compromised user credentials stolen from multiple breaches. Hackers can
re-use these passwords to infiltrate other user accounts with the same username/password combinations.

Fortinet’s Credential Stuffing Defense identifies login attempts using credentials that have been compromised, using an
always up-to-date feed of stolen credentials. Administrators can configure their supported devices to take various actions if a
suspicious login is used including logging, alerts, and blocking. In this lab, you use FortiWeb advanced protection to track
users connecting to a website and block stolen credential access.

Tasks

Testing Credential Stuffing

In this exercise, you will log in to the DVWA website using stolen credentials before applying FortiWeb credential defense.

1. On the Kali machine open Firefox.

2. Click the DVWA bookmarked page.

3. Log in using the following credentials:

Username: [email protected] Password: Snatch01

Note: this combination is considered a stolen credential, by FortiGuard

4. Click Logout and close Firefox.

Configure a User Tracking Rule

1. On FortiWeb click Tracking > User Tracking > User Tracking Rule.

Web Application and API Security Lab Guide

Page 30 of 85 Fortinet Training Institute
2. Click Create New and configure the following:

Name: tracking-rule-ACMECORP

Authentication URL: /DVWA/login.php

Username Field: Username

Password Field: Password

Session ID Name: PHPSESSID

Logoff Path: /DVWA/logout.php

Toggle on Credential Stuffing Defense

Action: Alert & Deny

Severity: High

3. Click Ok

Configure a Tracking Policy

1. Click Tracking > User Tracking > User Tracking Policy.

2. Click Create New.

3. Set the Name to tracking-policy and click OK.

Web Application and API Security Lab Guide

Page 31 of 85 Fortinet Training Institute
4. Click Create New.

5. Set the User Tracking Rule to tracking-rule-ACMECORP and click OK.

6. Click OK.

Apply the User Tracking Rule

1. Click Policy > Web Protection Profile.

2. Select protection1 and click Edit.

3. In the Tracking section, set User Tracking to tracking-policy.

4. Click OK

Web Application and API Security Lab Guide

Page 32 of 85 Fortinet Training Institute
4.3. Test Credential Stuffing Defense

Tasks

1. On Kali open Firefox and click the DVWA browser bookmark. Use the following credentials to sign in:

Username: [email protected] Password: Snatch01

2. The browser displays a web page blocked message.

3. Close the browser

Review the Attack Logs

1. On FortiWeb, click Log&Report > Log Access > Attack and review the most recent entry.

Question

What does FortiWeb use to check for Stolen username/password pairs?

Select the correct answer(s)

FortiWeb Local Database

FortiGuard Database

Web Application and API Security Lab Guide

Page 33 of 85 Fortinet Training Institute
4.4. Enable User Tracking

Background

In this exercise, you enable user tracking on FortiWeb. This allows you to track sessions by user and to capture a username
to reference in log messages. This information gives you more granular control over access to web resources, as well as
improving post-attack forensic analysis.

Tasks

Configure a User Tracking Rule

1. On Fortiweb. Click Tracking > User Tracking > User Tracking Rule.

2. Edit the tracking-rule-ACMECORP

Turn on Session Timeout

Timeout: 1

Turn on Session Timeout Enforcement

Session Freeze Time: 1

3. Click Ok

Define an Authentication Condition

1. Under the Authentication Result Condition Table, click Create New.

2. Configure the following settings:

Web Application and API Security Lab Guide

Page 34 of 85 Fortinet Training Institute
 HTTP Match Target: Return Code

Value Type: Simple String

Value: /index.php

3. Click OK.

4. Click on CLI Console in the top right corner to open it.

5. Configure the following:

# config waf user-tracking rule

# edit tracking-rule-ACMECORP

# set default-action success

# end

6. Close the console.

Web Application and API Security Lab Guide

Page 35 of 85 Fortinet Training Institute
4.5. Test User Tracking

Tasks

1. On Kali, using Mozilla Firefox, click the DVWA browser bookmark. Use the following credentials to sign in:

Username: admin Password: password

2. Click Command Injection and enter the following command: www.acmecorp.net;cd ../../;ls

3. The browser displays a web page blocked message

4. Wait one minute without interacting with the website to allow the timeout period to pass.

Review the Attack Logs

1. On FortiWeb, click Log&Report > Log Access > Attack and review the most recent entries

2. Select the generated attack log. In Detailed Information, click More Details. Locate the Username field. It indicates
that the attack was generated by the admin.

Web Application and API Security Lab Guide

Page 36 of 85 Fortinet Training Institute
4.6. Enable HTTP Authentication

Background

In this exercise, you apply HTTP authentication to protect defined websites using their hostnames. This supports PCI DSS
requirements by limiting access to resources for specific users and user groups.

Although many web applications may provide their authentication capabilities, using FortiWeb authentication ensures that
even web applications without native authentication capabilities are covered. It also allows for a single, centrally managed
user authentication mechanism, rather than managing each application separately.

An HTTP authentication policy can include many websites with common connection timeouts, session caches, and other
identical settings. During the testing phase of this lab, you view all authentication attempts, not just failures, so you will also
log successful attempts.

Tasks

Define the Protected Hostnames

1. Click Server Objects > Protected Hostnames.

2. Click Create New.

3. Set Name to hostname-ACMECORP.

4. Set Default Action to Deny.

5. Click OK.

6. Click Create New to add a host.

7. Set Host to www.acmecorp.net

8. Set Action to Accept

Web Application and API Security Lab Guide

Page 37 of 85 Fortinet Training Institute
 9. Click OK.

10. Click Create New to add another host.

11. Set Host to 172.16.99.124.

12. Set Action to Accept.

13. Click Ok

Note: If this server hosts websites for many domains, including subdomains such as store.example.com, you should add
all the domain names as hosts.

Define Users and User Groups

1. Click User > Local User.

2. Click Create New and configure the following settings:

Name: Web User

User Name: user1
Password: Fortinet1!

3. Click OK.

4. Click User > User Group > User Group.

5. Click Create New.

6. Set Name to user-query-ACMECORP.

7. Set Auth Type to Basic

8. Click OK.

9. Click Create New to define a user group member.

10. Set User Type to Local User.

11. Set Name to Web User.

Web Application and API Security Lab Guide

Page 38 of 85 Fortinet Training Institute
12. Click Ok

Define Authorized Accounts to a specific URL

1. Click Application Delivery > Authentication > Authentication Rule.

2. Click Create New.

3. Configure the following settings:

Name: ACMECORP-realm

Host Status: On

Host: www.acmecorp.net

4. Click OK.

5. While still on the same page, click Create New to add a new authentication rule.

6. Configure the following settings:

Auth Type: Basic

User Group: user-query-ACMECORP

Web Application and API Security Lab Guide

Page 39 of 85 Fortinet Training Institute
 User Realm: Employees Only

Auth Path: /

7. Click Ok

Configure the HTTP Authentication Policy

1. Click Application Delivery > Authentication > Authentication Policy

2. Click Create New and configure the following settings:

Name: HTTP-Auth-settings-ACMECORP

Connection Timeout: 2000

Turn on Cache

Cache Timeout: 15

Alert Type: All

Note: The configured cache timeout is set to 15 seconds in this exercise for testing purposes, so you do not have to
wait long for the authentication session to expire. In a production environment, you should set to cache timeout to 300
seconds or higher.

3. Click OK.

4. Click Create New to add a realm.

5. Set Auth Rule to ACMECORP-realm

Web Application and API Security Lab Guide

Page 40 of 85 Fortinet Training Institute
6. Click Ok.

Apply the Authentication and Authorization Settings

1. Click Policy > Web Protection Profile.

2. Select protection1 and click Edit.

3. In the Application Delivery section, set HTTP Authentication to HTTP-auth-settings-ACMECORP.

4. Click OK

Web Application and API Security Lab Guide

Page 41 of 85 Fortinet Training Institute
4.7. Test HTTP Authentication

Tasks

Note: You must wait 15 seconds between each test and then restart your browser.

1. On Kali, connect to http://www.acmecorp.net. This connection requires authentication.

2. Open a new tab and connect to the virtual server IP address: http://100.65.0.124/.

3. Open a new tab and visit http://www.acmecorp.net/. It prompts for authentication, as expected.

4. Enter the following credentials:

User name: user1

Password: Fortinet1!

Question

Why did you not get a user authentication prompt when browsing to http://100.65.0.124/?

Select the correct answer(s)

Only the domain name was specified in the authentication Policy

The browser cache have stored the login credentials

That address already uses native authentication

Only the domain name was specified in the host configuration of authentication rule

Web Application and API Security Lab Guide

Page 42 of 85 Fortinet Training Institute
5. Implement Certificates and Encryption
Background

PCI DSS requirements state that you must encrypt all cardholder data across open, public networks. This is achieved by
using SLL/TLS-secured HTTP, otherwise known as HTTPS.

In this lab, you prepare FortiWeb to take on the SSL security functions offered by your website. You will upload the
certificates and keys to FortiWeb and then offload the SSL (HTTPS) functions to FortiWeb. This ensures that all connections
to your website are secured by FortiWeb already. In this way, you can use SSL from the client to FortiWeb.

Finally, you implement HTTPS redirection to ensure that all traffic between the client and the web server is secured.

Objectives

Upload a signed certificate and private key to FortiWeb

Configure FortiWeb to provide HTTPS service, instead of your backend servers

Disable weak cryptography

Redirect HTTP requests to secure HTTPS and configure clients to use HTTPS-only access for subsequent requests

Time to Complete:
Estimated: 25 minutes

Web Application and API Security Lab Guide

Page 43 of 85 Fortinet Training Institute
5.1. Initialization

Initial Configuration for this Lab

To complete this objective, the FortiWeb must be preconfigured correctly.

Clicking Continue will perform a configuration restore on the FortiWeb.

Communications with the FortiWeb will be briefly interrupted while the restore process completes.

Web Application and API Security Lab Guide

Page 44 of 85 Fortinet Training Institute
5.2. Uploading a Server Certificate and Private Key

Background

In this exercise, you upload a preconfigured certificate and key to FortiWeb to use for HTTPS and SSL connections to your
website.

You also configure FortiWeb to offer HTTPS (performing the certificate and cryptographic operations) to clients for all
backend web servers.

Tasks

Import the Server Certificates

1. From the Lab Activity: FortiWeb sidebar menu, access Jumpbox using the RDP option.

2. Open the Mozilla Firefox browser and browse to the bookmarked FortiWeb page

3. Click Server Objects > Certificates > Local and click Import.

4. Set Type to Certificate.

5. Click Upload to select the Certificate file and Key file. The files for both, server.crt and server.key, are located in the
Web Server-Certificate file on the Desktop. Password is Fortinet1!

6. Click Ok

Download Backup Files

1. Click System > Maintenance > Backup & Restore.

2. Select Backup and Backup entire configuration. Leave all settings at default.

Web Application and API Security Lab Guide

Page 45 of 85 Fortinet Training Institute
 3. Click Backup.

4. Select Save File and click OK.

5. On Firefox, browse to the download arrow icon on the top right corner and browse to the download folder.

6. Rename the file, and add unencrypted to the name.

7. Create a second backup file, this time turning on Encryption and setting the Password to Fortinet1!

8. Click Backup.

9. Select Save File and click OK.

10. In the download folder, extract both configurations from the downloaded ZIP files, right-click on each file, and click 7-zip
> Extract files, when extracting the encrypted file, you will need to use the password.

Note: if you try to extract encrypted file using extract all the extraction will be errored.

11. Open both configuration files in a text editor, such as Notepad++, and compare their contents.

Web Application and API Security Lab Guide

Page 46 of 85 Fortinet Training Institute
Question

What critically sensitive information is stored in the configuration backup?

Select the correct answer(s)

Virtual IP addresses

Server certificate

Server private key

User names and passwords

Web Application and API Security Lab Guide

Page 47 of 85 Fortinet Training Institute
5.3. Implementing HTTPS Offloading

Background

In this exercise, you configure FortiWeb to manage all of the HTTPS communications with your website rather than
depending on the web server itself. This is called HTTPS offloading.

With HTTPS offloading, FortiWeb handles all of the secure connections with the client, while the connection between
FortiWeb and the web application is left unsecured. This moves the workload of encrypting and unencrypting closer to the
client and off of the server, allowing the server to focus its resources on serving the web application.

Tasks

Configure the FortiWeb HTTPS Service

1. On FortiWeb. Click Policy > Server Policy.

2. Select ServerPolicy_ACMECORP and click Edit.

3. Set HTTPS Service to HTTPS and set the Certificate to server.

4. Click Advanced SSL settings.

5. In the SSL Connection Settings section, set the SSL/TLS Encryption Level to High.

6. Click OK.

Web Application and API Security Lab Guide

Page 48 of 85 Fortinet Training Institute
7. Verify that the Web Protection Profile is set to protection1.

8. Click OK

Test HTTPS offloading

1. On Kali. Visit https://www.acmecorp.net/.

2. The ACMECORP Billing Portal page opens. Note the padlock icon and https:// in the address bar.

Question

Secure access using HTTPS is now working. What do you think would happen if you were to attempt to visit the site using the
plain HTTP URL http://www.acmecorp.net ?

Select the correct answer(s)

Request would be automatically redirected to HTTPS

Request would fail with a Page Not Found error

Request would be redirected to a Site Unavailable page

Request would successfully complete and the unsecured site would be shown.

Web Application and API Security Lab Guide

Page 49 of 85 Fortinet Training Institute
5.4. Rewriting and Redirecting HTTP to HTTPS

Background

To ensure your website is as secure as possible, it should only use HTTPS. In this exercise, you configure FortiWeb to redirect
HTTP requests to HTTPS for all web requests so all clients are automatically directed to the secure, encrypted, protocol.

Tasks

Edit the Server-Policy

1. On FortiWeb, click Policy > Server Policy.

2. Edit ServerPolicy_ACMECORP.

3. Enable Redirect HTTP to HTTPS.

Test HTTP Redirection

1. On Kali, open Mozilla Firefox and click on the AcmeCorp Login bookmark.

2. The ACMECORP Billing Portal page opens. Note the padlock icon and https:// in the address bar.

Web Application and API Security Lab Guide

Page 50 of 85 Fortinet Training Institute
6. Protect Against Zero-Day Attacks Using Machine Learning
Protect Against Zero-Day Attacks Using Machine Learning

In this lab, you implement the FortiWeb machine learning anomaly detection feature. This feature will allow you to quickly
and easily provide a high level of protection for your web application.

You also use some penetration testing tools to test, observe, and review machine learning anomaly detection in action.

Objectives

Configure anomaly detection to observe the traffic of your web applications and anticipate security needs

Use penetration testing tools to teach anomaly detection of normal traffic patterns

Observe the machine-learning process

Test your protection

Time to Complete:
Estimated: 45 minutes

Web Application and API Security Lab Guide

Page 51 of 85 Fortinet Training Institute
6.1. Initialization

Initial Configuration for this Lab

To complete this objective, the FortiWeb must be preconfigured correctly.

Clicking Continue will perform a configuration restore on the FortiWeb.

Communications with the FortiWeb will be briefly interrupted while the restore process completes.

Web Application and API Security Lab Guide

Page 52 of 85 Fortinet Training Institute
6.2. Configuring Machine Learning Anomaly Detection

Background

In this exercise, you configure FortiWeb machine learning anomaly detection to more effectively protect your web
application.
Although the currently configured policy has protection enabled, the protection1 profile is configured in such a way that
FortiWeb only blocks known attacks, based on defined signatures.

By enhancing FortiWeb with machine learning anomaly detection, FortiWeb can block unknown, suspicious traffic for which
signatures do not yet exist. These are often referred to as zero-day attacks.

By default, when machine learning is in its collecting phase, FortiWeb will accept only 30 requests from the same IP. For
testing purposes, you configure the policy to accept unlimited samples from the same IP.

FortiWeb ML by default is set to receive HTTP requests containing the parameter/argument from a minimum number of 3 (ip-
expire-cnts) different source IP addresses within the given period of 4 hours (ip-expire-intval). In this Lab FortiWeb will
receive HTTP requests from one IP address, you will need to change ip-expiry-cnts to 1 later in this exercise to avoid having
the HMM learning stage showing Unconfirmed.

Machine learning anomaly detection is the last layer in the FortiWeb protections. It is applied after all other protection
features have already been applied, such as IP reputation, DoS protections, antivirus, signatures, and so on.

Tasks

Update the Server Policy

1. On FortiWeb. Click Policy > Server Policy.

2. Select ServerPolicy_ACMECORP and click Edit.

3. In the Security Configuration section, set Web Protection Profile to <blank selection> as shown in the image below
to disable this profile.

Note: Web protection is disabled in this exercise for demonstration purposes only, to ensure that later results are
obtained using machine learning anomaly detection.

Web Application and API Security Lab Guide

Page 53 of 85 Fortinet Training Institute
 4. Click OK.

5. Select ServerPolicy_ACMECORP again and click Edit.

6. Expand the Machine Learning section, select Anomaly Detection, and click Create.

7. Set Domain to www.acmecorp.net

8. Click OK.

9. Icons appear under Machine Learning. The gear icon indicates that machine learning is turned on.

10. Click Ok

Configure the Machine Learning Policy

1. Click Web Protection > ML Based Anomaly Detection

2. Select ServerPolicy_ACMECORP and click Edit.

Web Application and API Security Lab Guide

Page 54 of 85 Fortinet Training Institute
3. Enable Advanced Settings and under Anomaly Detection Settings, set Strictness Level for Anomaly to 1.

Note: In a production environment, you should use a higher threshold for the strictness level.

4. Click OK.

5. Select ServerPolicy_ACMECORP and click Edit.

6. Under Domain Settings double-click www.acmecorp.net.

7. Click the Tree View tab. No data is shown because the web server is not currently receiving HTTP requests.

8. Click the Parameter View tab. No data is shown because the web server is not currently receiving HTTP requests.

Configure Machine Learning Limits

1. Click the console icon ( ), in the upper right of the GUI, to connect to the CLI.

2. Click the detach icon ( ) to open the web console in a new browser tab.

3. Type the following commands:

config waf machine-learning-policy

edit 1

set sample-limit-by-ip 0

Web Application and API Security Lab Guide

Page 55 of 85 Fortinet Training Institute
 next

end

4. Type show waf machine-learning-policy and confirm that the settings you entered appear.

5. Close the console tab

Web Application and API Security Lab Guide

Page 56 of 85 Fortinet Training Institute
6.3. Establishing The Model

Background

Although FortiWeb is currently configured to perform machine learning anomaly detection, the device has not yet learned
anything about the normal traffic patterns for the network.

In this exercise, you send HTTP requests to the web application to see how machine learning works. You first teach FortiWeb
about normal traffic patterns and then you send abnormal traffic to see how anomaly detection protects your servers.

It can take a while for the collecting, building, testing, and running stages to complete, but clicking the refresh button, as
indicated below, allows you to see the percentage of the stage that is completed.

Tasks

Generate Normal Traffic

1. On Kali. Click the terminal icon on the system bar (upper left corner of the screen).

2. Enter ./wfuzzscript.sh test1 5 and then press Enter. This script makes 2000 unique HTTP GET requests, looping
five times to give machine learning enough time to build a traffic model. The console shows the requests being sent to
FortiWeb.

3. Leave the script running and the Kali browser tab open.

4. On FortiWeb, click Web Protection > ML Based Anomaly Detection.

5. Double-click the defined server policy to edit it.

6. Under Domain Settings double-click www.acmecorp.net domain to view settings.

7. Click the Parameter View tab. FortiWeb shows information about the productID parameter that was discovered from
monitoring the HTTP requests destined for the web application. Note that the HMM Learning Stage is Collecting.

Web Application and API Security Lab Guide

Page 57 of 85 Fortinet Training Institute
 8. Click refresh ( ) to see the collecting stage continue.

9. Continue clicking refresh every 30 seconds to see the HMM Learning Stage change to Building.

10. Continue clicking refresh, every 30 seconds to see the HMM Learning Stage change to Running.

11. Return to the Kali browser tab and enter Ctrl + C in the terminal window to end the script.

Review Machine Learning Status

1. On FortiWeb, click the Tree View tab. Expand URLs and click productlookup

2. View the parameters linked to productlookup, as well as what learning stage each parameter is in.

3. Click the Overview tab. The lower-right widget shows the machine-learning events.

4. Event logs show <ProductID> change from None to Collecting, Collecting to Building, Building to Running.

5. Click the Parameter View tab and click productID.

6. View the Distribution of Anomalies triggered by HMM table. It displays which samples were considered anomalies
when the HMM model was being built, as well as the sample length. In this example, there are no anomalies.

Web Application and API Security Lab Guide

Page 58 of 85 Fortinet Training Institute
Test the Current Configuration

1. On Kali, open Mozilla Firefox and click the Product Lookup browser bookmark.

2. Enter AAAAA for ProductID and click Search.

3. The site accepts the input on the Product Lookup page, and responds with a message indicating the product is not
found.

4. From the sidebar menu, access FortiWeb using the HTTPS option.

5. Click Log&Report > Log Access > Attack. There are no log entries.

Question

Why did FortiWeb not block the AAAAA input on the Product Lookup page?

Select the correct answer(s)

FortiWeb is unable to distinguish between letters and numbers

FortiWeb detected an anomoly, but recognized that it was not a threat

FortiWeb was unable to detect the threat, so ignored it.

This would have been detected by a signature, not machine learning

Web Application and API Security Lab Guide

Page 59 of 85 Fortinet Training Institute
6.4. Protecting and Adapting

Background

In this exercise, you use scripts to generate attacks against your protected web servers.

This allows you to observe the machine learning capabilities.

By reviewing log entries and threat models, you can see how FortiWeb protects your web applications.

You also change the format the web application uses for the product ID, to see how the machine learning model can learn
about, and automatically adjust to, changes to the web application.

Tasks

To generate an attack

1. On Kali, open the terminal window.

2. Enter the following command to send malicious requests to the web application’s ProductID parameter:

./wfuzzscript.sh attacks 1

3. There is a 500 response code in the script's outputs, indicating that the attack was not allowed through to the destination.

Review the Logs

1. On FortiWeb, Click Log&Report > Log Access > Attack.

2. Hover your mouse pointer over the header bar until the settings icon appears on the left side.

Question

When FortiWeb is scanning traffic for threats, at what point in the scan sequence is the machine learning applied?

Select the correct answer(s)

After IP Reputation, but before Signatures

Web Application and API Security Lab Guide

Page 60 of 85 Fortinet Training Institute
 After Signatures, but before Anti virus scans

Final mechanism, as a last line of defence to catch all unrecognized threats

As part of the Integration with FortiSandbox and FortiGate

Web Application and API Security Lab Guide

Page 61 of 85 Fortinet Training Institute
7. Known Bot Mitigation
Known Bot Mitigation

Known Bots protects your websites, mobile applications, and APIs from malicious bots such as DoS, Spam, and Crawler,
etc, and known good bots such as known search engines without affecting the flow of critical traffic. In this section, you will
be testing Wotbox known bot using curl and enable known bot protection to deny the wotbox curl request.

Objectives

Known Bot Test.

Known Bot Protection.

Test Known Bot protection

Time to Complete
Estimated: 15 minutes

Web Application and API Security Lab Guide

Page 62 of 85 Fortinet Training Institute
7.1. Initialization

Initial Configuration for this Lab

To complete this objective, the FortiWeb must be preconfigured correctly.

Clicking Continue will perform a configuration restore on the FortiWeb.

This will cause the FortiWeb to reboot.

Communications with the FortiWeb will be briefly interrupted while the restore process completes.

Web Application and API Security Lab Guide

Page 63 of 85 Fortinet Training Institute
7.2. Known Bot Test

Background

In this lab you will use a known bot called Wotbox, you will run a curl command with the Wotbot user agent to get acme
corp's login webpage content.

Tasks

Test wotbox with curl

1. On the Kali machine, open the terminal from the left sidebar.

2. Type curl -A "Wotbox/2.01 (+http://www.wotbox.com/bot/)" http://www.acmecorp.net

3. You will get the page content since known bot mitigation is not enabled yet.

Web Application and API Security Lab Guide

Page 64 of 85 Fortinet Training Institute
 7.3. Known Bot Protection

Background

In this lab, you will be configuring Known Bot protection, applying it to the Bot Mitigation Policy, applying the policy to the
protection1 profile, and testing known bot protection.

Tasks

Configure Known Bot Protection

1. On Fortiweb, click Bot Mitigation > Known Bots.

2. Click Create New.

3. Set the Name to KnownBotProtection.

4. Click OK.

5. Click Bot Mitigation > Bot Mitigation Policy.

6. Click Create New.

7. Set the Name to Known Bot Protection.

8. Set Known Bots to KnownBotProtection.

9. Click OK.

10. Click Policy > Web Protection Profile.

11. Edit protection1.

12. Set Bot Mitigation Policy to Known Bot Protection.

13. Click Ok

Web Application and API Security Lab Guide

Page 65 of 85 Fortinet Training Institute
7.4. Test Known Bot Protection.

Tasks

1. On Kali use the terminal to run the following command again

curl -A "Wotbox/2.01 (+http://www.wotbox.com/bot/)" http://www.acmecorp.net

2. The request will be blocked, and the output will be random characters.

3. On the FortiWeb click Log&Report > LogAccess > Attack to view the deny log.

Web Application and API Security Lab Guide

Page 66 of 85 Fortinet Training Institute
8. Injection
Injection

As stated by OWASP Top 10 2021, injection slides down to the third position compared to OWASP Top 10 2017. 94% of the
applications were tested for some form of injection with a max incidence rate of 19%, an average incidence rate of 3%, and
274k occurrences.

As there are many Injection attacks, in this lab, you will perform injection attacks on the DVWA specifically SQLi and Cross
Site Scripting. Injection is listed as A03:2021-Injection under the OWASP Top 10 2021. After performing the attacks, you will
deploy a protection profile on the FortiWeb and test how FortiWeb protects against SQLi and XSS attacks.

Objectives

Perform an SQLi attack and test FortiWeb protection against SQLi

Perform an XSS attack and test FortiWeb protection against XSS

Time to Complete
Estimated: 30 minutes

Web Application and API Security Lab Guide

Page 67 of 85 Fortinet Training Institute
8.1. Initialization

Initial Configuration for this Lab

To complete this objective, the FortiWeb must be preconfigured correctly.

Clicking Continue will perform a configuration restore on the FortiWeb.

Communications with the FortiWeb will be briefly interrupted while the restore process completes.

Web Application and API Security Lab Guide

Page 68 of 85 Fortinet Training Institute
8.2. SQLi Attack and FortiWeb Protection

Background

An SQL injection attack is one of the most dangerous web application attacks listed in OWASP's top 10 A03:2021
vulnerabilities which mostly occur due to insufficient user input validation. It’s a technique where SQL code/statements are
inserted in the execution field to alter the database contents, dumping useful database contents to the hacker, causing
repudiation issues, spoofing identity, and much more.

In this exercise, you will perform an SQLi attack on DVWA and test the FortiWeb protection against SQLi.

Tasks

Perform an SQLi Attack on DVWA

1. From the Lab Activity: FortiWeb sidebar menu, access Kali using the RDP option.

2. Open Mozilla Firefox and access the bookmarked page DVWA using the following credentials to sign in.

Username: admin Password: password

3. Click SQL Injection

4. Enter the User ID:

%' or 0=0 union select null, user() #

this is the SQL Injection that displays the database Users.

5. Click Submit. As you can see this site accepted the SQLi and displayed the user’s info.

6. Close the browser

Web Application and API Security Lab Guide

Page 69 of 85 Fortinet Training Institute
FortiWeb Protection against SQLi

1. From the Lab Activity: FortiWeb sidebar menu, access FortiWeb using the HTTPS option

2. Click Web Protection > Known Attacks > Signatures

3. Double click signature1

4. Enable the SQL Injection Signature and make sure the Action is set to Alert&Deny.

5. Click OK

6. Click Policy > Web Protection Profile.

7. Double-click the protection1 profile.

8. Edit the Signatures entry and select signature1

9. Click OK

Web Application and API Security Lab Guide

Page 70 of 85 Fortinet Training Institute
10. Click Policy > Server Policy

11. Double-click ServerPolicy_ACMECORP

12. Verify Web Protection Profile is set to protection1

13. On Kali, browse to the DVWA bookmarked page.

14. Click SQL Injection

15. Enter the User ID: %' or 0=0 union select null, user() # this is SQL Injection that displays database Users.

16. Click Submit

17. FortiWeb blocked this attempt.

18. Close the browser

19. On FortiWeb browse to Log&Report > LogAccess > Attack to view the SQL Injection attack log. Please add the Main
Type and Sub Type columns back. You can double-click on that log for more details.

Web Application and API Security Lab Guide

Page 71 of 85 Fortinet Training Institute
8.3. XSS Attack and FortiWeb Protection

Background

An XSS attack occurs when an attacker uses a web application to send malicious code or a browser-side script, to a different
end user. The victim has no way of knowing that the script is malicious thus believing that it is from a trusted source. The
malicious script can access cookies, session tokens, or other sensitive information stored by the browser and used with the
site.

The bad news is XSS is widespread and can be very dangerous making it one of the OWASP Top 10 vulnerability A03:2021-
Injection. The good news is it can be easily prevented through proper sanitization of user inputs.

While the goal of an XSS attack is always to execute malicious JavaScript in the victim's browser, there are a few
fundamentally different ways of achieving that goal. XSS attacks are often divided into three types:

Persistent XSS, where the malicious string originates from the website's database.

Reflected XSS, where the malicious string originates from the victim's request. The website then includes this malicious
string in the response sent back to the user.

DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code. DOM-based XSS is a
variant of both persistent and reflected XSS. In a DOM-based XSS attack, the malicious string is not parsed by the victim's
browser until the website's legitimate JavaScript is executed.

Tasks

Perform XSS Attack on DVWA

1. On the Kali machine, open Mozilla Firefox and access the browser bookmarked page DVWA.

2. Click XSS (Reflected).

3. Enter in the What’s your name: “ <script> alert('this is xss') </script> “

4. Click Submit. As you can see the output indicates the website is vulnerable to XSS.

5. Click OK.

6. Close browser.

Web Application and API Security Lab Guide

Page 72 of 85 Fortinet Training Institute
 FortiWeb Protection against XSS

1. On the FortiWeb, click Web Protection > Known Attacks > Signatures

2. Double click signature1

3. Enable the Cross Site Scripting Signature and make sure the Action is set to Alert&Deny

4. Click OK

5. Click Policy > Web Protection Profile.

6. Double-click protection1 profile.

7. Verify Signatures is set to signature1

8. Click OK

9. Click Policy > Server Policy

10. Double click ServerPolicy_ACMECORP

11. Verify the Web Protection Profile is set to protection1

12. On Kali, browse to the DVWA bookmarked page.

Web Application and API Security Lab Guide

Page 73 of 85 Fortinet Training Institute
13. Click XSS (Reflected).

14. Enter in the What’s your name: “ <script> alert('this is xss') </script> “

15. Click Submit

16. FortiWeb blocked this attempt.

17. Close the browser

18. On FortiWeb browse to Log&Report > LogAccess > Attack to view the Cross Site Scripting attack log. You can
double-click on that log for more details.

Web Application and API Security Lab Guide

Page 74 of 85 Fortinet Training Institute
9. Securing Your Cookie
Securing Misconfiguration

As stated by OWSAP Top 10, 90% of applications were tested for some form of misconfiguration, with an average incidence
rate of 4%, and over 208k occurrences of a Common Weakness Enumeration (CWE) in this risk category. Web application
misconfiguration can be for many reasons, defaults account and their passwords are enabled, and unchanged, unnecessary
features are enabled, and more.

This Lab will go through CWEs like the Sensitive Cookie in HTTPS session without secure attribute and HttpOnly flag and how
FortiWeb cookie security policy allows you to prevent cookie-based attacks.

Objectives

FortiWeb Protection for cookies without HttpOnly

Test FortiWeb Protection for cookies without HttpOnly

FortiWeb Protection for a cookie without the Secure attribute

Test FortiWeb Protection for a cookie without the Secure attribute

Time to Complete
Estimated: 30 minutes

Web Application and API Security Lab Guide

Page 75 of 85 Fortinet Training Institute
9.1. Initialization

Initial Configuration for this Lab

To complete this objective, the FortiWeb must be preconfigured correctly.

Clicking Continue will perform a configuration restore on the FortiWeb.

Communications with the FortiWeb will be briefly interrupted while the restore process completes.

Web Application and API Security Lab Guide

Page 76 of 85 Fortinet Training Institute
9.2. Protection For Cookie without HttpOnly

Background

Using the HttpOnly flag when generating a cookie helps mitigate the risk of a client-side script accessing the protected
cookie (if the browser supports it).

If the HttpOnly flag is included in the HTTP response header, the cookie cannot be accessed through a client-side script.

As a result, even if an XSS flaw exists and a user accidentally accesses a link that exploits this flaw, the browser will not
reveal the cookie to a third party.

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access
the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing
through XSS attacks.

This lab will go through the exercise where the attacker reveals the value of the cookie as the HttpOnly flag is not enabled
for the DVWA website and how FortiWeb prevents this by enforcing the HttpOnly using the Cookie Policy. The HttpOnly flag
tells the browser that the cookie can only be accessed through HTTP.

Tasks

1. From the Lab Activity: FortiWeb sidebar menu, access Kali using the RDP option.

2. Open Mozilla Firefox and access the bookmarked page DVWA using the following credentials to sign in:

Username: admin Password: password

3. On the top right corner click on Menu then click Web Developer.

4. Click Storage Inspector.

5. You will see that table.header.cookies.isHttpOnly field is set to false for both PHPSESSID and security, if you click
on any of those you will see in the Data Section on far right HttpOnly:false, which means that the HttpOnly flag is off.

6. Close the Storage Tab

7. Click XSS (Reflected)

8. In the What’s your name field, enter: ”<script>alert(document.cookie)</script>”

Web Application and API Security Lab Guide

Page 77 of 85 Fortinet Training Institute
 9. Click Submit

10. You will see that the browser revealed the PHPSESSID and security cookies values when subject to XSS because the
HttpOnly flag is misconfigured on the DVWA web server.

11. Click OK

12. Close the browser

13. From the Lab Activity: FortiWeb sidebar menu, access FortiWeb using the HTTPS option.

14. Click Web Protection > Cookie Security

15. Click Create New

16. Name: Cookie Protection Policy

Security Mode: Signed

17. Under Cookie Security Attributes, enable HTTP Only

18. Set Action to Alert & Deny

19. Click OK

20. Click Policy > Web Protection Profile

21. Double click protection1

22. Set the Cookie Security Policy to Cookie Protection Policy.

Web Application and API Security Lab Guide

Page 78 of 85 Fortinet Training Institute
23. Click OK

Note: Just for the purpose of this exercise, the Signature in the protection profile is not set to any. To demonstrate XSS is
not being blocked.

Web Application and API Security Lab Guide

Page 79 of 85 Fortinet Training Institute
9.3. Test Protection for Cookie without HttpOnly

Tasks

1. On the Kali machine, open Mozilla Firefox and browse to the DVWA booked marked page, click again on
XSS(Reflected), and enter in the What’s your name field:”<script> alert(document.cookie)</script>“.

2. You will notice that the browser did not reveal the cookie's value when subject to XSS and having the browser asked by
Java script to reveal the cookie value.

Note: make sure a new browser session is opened when doing step 24.

3. Close the browser

Web Application and API Security Lab Guide

Page 80 of 85 Fortinet Training Institute
9.4. Protection For Cookie without Secure attribute

Background

A cookie is subject to vulnerability if the secure attribute is not set. If an attacker can intercept HTTP traffic using a man-in-
the-middle attack, they may be able to steal another user’s cookie and impersonate them.

Set your cookies to be secure, so they can only be sent over HTTPS. This will prevent all but the most sophisticated man-in-
the-middle-attacks, and prevent cookies from being observed by unauthorized parties due to the transmission of the cookie
in clear text.

In this exercise will demonstrate how FortiWeb sets secure attributes in the HTTP response using the cookie security policy.

Tasks

1. On the FortiWeb, click Web Protection > Cookie Security.

2. Double click Cookie Protection Policy

3. Under Cookie Security Attributes enable Secure Cookie.

4. Click OK.

Note: make sure the browser is closed and a new browser session is opened in the next exercise.

Web Application and API Security Lab Guide

Page 81 of 85 Fortinet Training Institute
9.5. Test Protection For Cookie without Secure attribute

Tasks

1. On the Kali machine, open the browser and access the bookmarked page DVWA.

2. On the top right corner, click on Menu, then click on Web Developer

3. Click on Storage Inspector.

4. As you can see cookie information (PHPSESSID and security) is not available when browsing the DVWA.

5. Try to log in to the DVWA, you will not be able to.

6. Click on Network

7. Click on the POST HTTP traffic then click on Headers

8. You can drag the Dev tap up higher to view more info, under the Request headers check the cookies sent by the
browser, you will notice PHPSESSID and Security were not sent.

9. Navigate to the Response headers to check the response from FortiWeb/DVWA, under both the security and
PHPSESSID cookie, the secure flag is present.

Web Application and API Security Lab Guide

Page 82 of 85 Fortinet Training Institute
10. Close the browser

Question

Why were you not able to login to the DVWA website?

Select the correct answer(s)

secure attribute is missing from cookie

secure attribute is enabled for cookies thus browser is not sending cookie using HTTP

PHPSESSID cookie is not sent to DVWA web server

web server is not working

Web Application and API Security Lab Guide

Page 83 of 85 Fortinet Training Institute
10. Conclusion

After completing this Fast Track module, you should now understand how to:

Perform Initial FortiWeb configuration.

Configure and Secure Local logging.

Configuration sensitive data masking.

View FortiAnalyzer Remote logging configuration and log testing

Configure credential stuffing

Configurate user tracking

Secure Resource Access using FortiWeb Authentication.

Implement SSL/TLS offloading.

Protect Against Zero Day Attacks Using Machine Learning.

Implement known bot mitigation.

Perform an injection attack and use FortiWeb to protect against it

Secure your cookies with FortiWeb

Web Application and API Security Lab Guide

Page 84 of 85 Fortinet Training Institute
10.1. Continued Education

Congratulations!! You have completed the Web Applications and API Security workshop.

For continued learning about this solution, please consider looking at the following Fortinet NSE training course:

https://training.fortinet.com/local/staticpage/view.php?page=library_fortiweb-administrator

Web Application and API Security Lab Guide

Page 85 of 85 Fortinet Training Institute