What is the need for WAF?
Why do we need to protect web applications from attacks and why are web applications targeted by so many attacks?
The first reason is that we are using known technologies to develop web applications. Many popular web development platforms such as PHP and ASP have known security holes, and attackers use these weaknesses to exploit the application. The same is true of the database engines these applications use on the backend.
How to recover files permanently deleted from Onedrive
Configuring Azure Active Directory B2B, Guest User and Single Sign On
Guide for installing Microsoft Endpoint Configuration Manager (SCCM)
How to configure Passwordless in AzureAD/On-prem via the Microsoft Authenticator app
How to work with dynamic groups in Azure Active Directory
The second reason is the wide surface of the attacks. Top web application users are connecting from the internet. Anyone can try to use or attack your application from the internet.
Almost all of these attacks can be categorized into a few groups, SQL injection attacks, cross-site scripting, remote file inclusion, missing HTTP headers, bots, crawlers and scanners browsing the Internet trying to find weak web applications, excessive requests and much more.
All these attacks can be avoided. One way is to prevent at the code level, which is quite challenging and it's the developer's responsibility to do this. In addition, it requires high maintenance, patching, and monitoring across multiple application layers. The other, much simpler way is to buy web application firewall firewalls (WAFs) and deploy them in front of the web server to block common attacks. This provides centralized protection for your web application against common exploits and vulnerabilities.
a web application firewall (WAF) is a specific form of network security system that filters, monitors, and blocks incoming and outgoing HTTP and HTTPs traffic to and from a web service, based on a configured policy, usually with predefined sets of rules to choose from.
What is the Azure Web Application Firewall?
Microsoft Azure also has a WAF service that provides centralized protection of your web applications from common exploits and vulnerabilities. Azure Application Firewall is one of the features of Azure Application Gateway (layer 7 load balancer) and Azure Front Door, its main purpose is to protect a web application from common attacks such as SQL injections, cross-site scripting and others. It is also following the Open Web Application Security Project core ruleset (OWASP) . The Azure WAF service offers you the selection of some or all of the rules from the OWASP core ruleset.
Azure Application Gateway has a public IP, or frontend, and your application users will use that IP address to connect to your Application gateway. Application gateway will receive incoming traffic and, based on some rules, redirect traffic to the appropriate backend in the backend pool. You can have app services, virtual machine scale sets, or even other IP addresses in your backend pools.
- It can be configured, deployed and managed through the Azure portal, REST APIs, PowerShell and CLI.
- Works with all types of web applications (ASP.NET, PHP, JSP, etc.)
- No code changes are required at the application layer.
- Real-time protection monitoring logs.
- Customization of rules according to application requirements.
You find on here all other features of the service.
- Detection: monitors and records all threat alerts in a log file if we run WAF in “Detect” mode. In this mode, no incoming requests will be blocked and will be logged in WAF logs.
- Prevention: Detects and blocks incoming requests against attacks, and the attacker simply gets 403 Forbidden Error in “Prevention” mode. This mode also logs such attacks in the WAF logs.
For any application, it is recommended to start with WAF detection mode. Initially monitor the WAF logs for the selected rules, review the logs, and revisit the rule set to decide if the selected rule set is a correct match for the traffic to be blocked in prevention mode.
Azure Web Application Firewall charges are based on the version we chose during deployment:
- Web Application Firewall: here you will get the hourly price of an Azure Application Gateway with a medium size at least. Also, pricing is based on the amount of data the WAF will process.
- Web Application Firewall V2: Here you will get the hourly price and a cost based on the amount of “Capacity Units”. You can learn more about the capacity unit on here
Step by step
In this article we will use the Damn Vulnerable Web App (DVWA) application that will be published in a Windows virtual machine, to test the access of the vulnerable application with WAF, and how WAF will handle these application vulnerabilities.
Publishing the DVWA application on Windows
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is extremely vulnerable. Its main goals are to help security professionals test their skills and tools in a legal environment, help web developers better understand web application protection processes, and help teachers/students teach/learn web application security. web in a classroom environment.
The application is available for download from the link below.
01 – Download DVWA by clicking on DOWNLOAD.
Download and install XAMPP
XAMPP is a very easy to install Apache distribution for Linux, Solaris, Windows and Mac OS X. The package includes the Apache web server, MySQL, PHP, Perl, an FTP server and phpMyAdmin.
02 – Access the link below to download XAMPP.
03 – On the XAMPP website, click on Download.
04 – On the Download screen, select your operating system version and click Download.
05 – After downloading XAMPP, click on xampp-windows-x64-7.3.30-0-VC15-installer.exe to start the installation process.
06 – In the video below I show you how to install XAMPP.
07 – Start the Apache and MySQL services.
08 – After installing XAMPP and starting Apache and MySQL, navigate to the path C:\xampp\htdocs and delete all the contents of the folder.
09 – On the way C:\xampp\htdocs create a folder called dvwa and paste the contents of the DVWA file we downloaded.
10 – Inside the dvwa folder in the following path C:\xampp\htdocs\dvwa, enter the config folder.
11 – Inside the config folder, click on View and select File name extensions.
12 – I renamed the config.inc.php.dist file to config.inc.php, on the confirmation screen click Yes.
13 – Open the config.inc.php file, for the option $_DVWA[ 'db_password' ] = '[email protected]' leave this value empty, in change $_DVWA[ 'db_user' ] = 'dvwa' change the value to root, in then save the file.
14 – Open a browser and enter the following path to access the application localhost/dvwa
15 – Our next step will be to change the PHP function allow_url_include which is as Disabled, in the XAMPP Control in Apache click on Config and select PHP (php.ini).
16 – Press Control + F and type url_include then click Find Next.
17 – Change the value allow_url_include=Off to allow_url_include=On, then click Save.
18 – In Apache click on Stop and Start.
19 – Update the application setup page, and as we can see the status of the PHP function allow_url_include was changed to Enabled.
20 – On the dvwa application screen, scroll the scroll bar to the end of the page and click on Create/Reset Database.
21 – After clicking on Create/Reset Database the database will be created and we will automatically be redirected to the login screen.
22 – On the login screen, enter the username admin and the password password, then click Login.
Deploy Web Application Firewall (WAF)
23 – Log in to the Azure.
24 – In the Azure portal search for Application gateways.
25 – On the Application Gateway screen, click on + Create.
26 – On the Create application gateway screen in the Basics option, select the subscription and resource group.
In Instance details, for the Application gateway name option enter a name for the resource, in Region select the region where the resource was created, in Tier we can select both WAF and WAF V2, select WAF V2, for the Enabled autoscaling option select No, in Firewall status leave Enabled selected, in Fariwall mode we will select Prevention to block all malicious requests, for the Availability zone option select None and for the HTTP2 option we will leave it selected Disabled.
NOTE: WAF V2 supports autoscaling and WAF is not supported.
For Azure to communicate between the resources you create, it needs a virtual network. You can create a new virtual network or use an existing one, as I already have a vnet created let's select this vnet and create a subnet for the Application gateway. in Virtual network select the vnet you want, in Subnet if you have already created select the desired subnet, click on Manage subnet configuration.
The Subnet screen will open, click + Subnet, the Add subnet screen will appear enter a name for the subnet in Subnet address range enter the ip range for the subnet, leave the other settings as default and click Save.
Still on the subnet creation screen, click on Create application gateway to return to the application gateway creation screen.
Back on the Create application gateway in virtual network screen, select the subnet we created subnet-application_gateway, then click on Netx: Frontends.
27 – On the Frontends screen we can select the Public, Private and Both types, we will select Public then click on Add new, the Add a public IP screen will open, type a name for the resource and click on OK, then click on Next : Backends.
NOTE: We cannot use the Private or Both option with WAF 2.
28 – On the Backends screen click Add a backend pool, the Add a backend pool screen will open enter a name, in Target type we will select Virtual machine in Target select the virtual machine you want to add, then click Add.
NOTE: In backend we can add IP addres or FQDN, Virtual machine, VMSS and App Services.
Then click Next: Configuration.
29 – On the Configuration screen, click on + Add a routing rule.
30 – On the Add a routing rule screen, in Rule name enter a name for the rule, in Lister name enter a name, for the Frontend IP option select Public, in Protocol we can select HTTP or HTTPS, if you select HTTPS, enter the number from the port, choose a certificate option “Upload a certificate” or “Choose a certificate from Key Vault”, if you select Upload a certificate, select the PFX certificate file from your local machine and also enter the certificate name and password.
In this article we are going to use the HTTP protocol, select the HTTP protocol and port 80 in Additional settings but leave the Basic option selected, marking the Error page url option with yes we can customize the Bag gateway – 502 and Forbiddend – 403 error messages, let's leave it selecting No, then click on Backend targets.
Note: If you are hosting a single website behind this application gateway, choose a basic listener. If you are configuring more than one web application or multiple subdomains of the same parent domain, choose a multisite listener
In Backend targets, for the Target type option, leave the Backend pool selected and select which backend the rule should direct traffic to, let's select the backend that we created VMs-backendpool, for the Backend target option, click Add new.
We return to the Add a routing rule screen, click Add.
Back to the Create application gateway screen, we finished creating the routing rule, click Next: Tags.
31 – On the Tags screen, click Next: Review + create.
32 – On the Review + create screen, check if all the information is correct and click Create.
33 – Wait for the deployment to finish.
34 – As we can see the resource has been provisioned.
Enable Web Application Firewall Diagnostics Settings
35 – In the Azure portal search for Application gateways.
36 – On the Load balancing screen in Application Gateway, select the wafjadsonalves.
37 – In Monitoring click on Diagnostic settings.
38 – In Diagnostic settings, click on +Add diagnostic setting.
39 – In Diagnostic settings, type a name for the resource, check the options ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog, ApplicationGatewayFirewallLog and AllMetrcis. In Destination details select Send to Log Analytics workspace, select the subscription and a workspace exists if desired, then click Save.
40 – As we can see the waf diagnostic is configured.
Web Application Firewall policies
Associating a Web Application Firewall (WAF) policy with listeners allows multiple sites behind a single WAF to be protected by different policies. For example, if you have five sites behind your WAF, you can have five separate WAF policies (one for each listener) to customize exclusions, custom rules, and managed rule sets for one site without affecting the other four. If you want a single policy to apply to all sites, simply associate the policy with Application Gateway, rather than individual listeners, and it will apply globally. Policies can also be applied to a path-based routing rule.
41 – In the portal, search for Web Application Firewall policies (WAF).
42 – On the Web Application Firewall policies (WAF) screen, click Create.
43 – On the Create a WAF policy screen, in Policy for, select Regional WAF (Application Gateway), select the subscription and Resource group, in Instance details, select a name for the policy, in location, select the region where the resource will be created, leave the Policy state option enabled, in Policy mode select Prevention then click Next: Managed rules.
When creating a WAF policy, by default it is in default mode. Detection. In Discovery mode, WAF does not block any requests. Instead, the corresponding WAF rules are recorded in the WAF logs. To see WAF in action, change the mode settings to Prevention. In Prevention mode, match rules defined in the CRS rule set you selected are blocked and/or logged in the WAF logs.
44 – For the Managed rules option, in the Managed rule set we can choose between the options OWASP_.2 (preview), OWASP_3.1, OWASP_3.0, OWASP_2.2.9 and Microsoft_BotManageRuleSet_0.1, let's leave the default value selected. Azure managed OWASP rules are enabled by default. To disable an individual rule in a rule group, click Expand all, select the checkbox next to the rule number, and click disable in the tab above. For this configuration we will leave the default values click Next : Policy settings.
45 – On the Policy settings screen, we are not going to configure exclusions for the rule, click Next : Custom rules.
46 – On the Custom rule screen, click on + Add custom rule.
Azure Application Gateway Web Application Firewall (WAF) v2 comes with a preconfigured, platform-managed rule set that provides protection against many different types of attacks. These attacks include cross-site scripting, SQL injection, and others. If you are a WAF administrator, you might want to write your own rules to augment the core ruleset (CRS) rules. Your rules can block or allow requested traffic based on match criteria.
Custom rules allow you to create your own rules that are evaluated for each request that passes through the WAF. These rules have a higher priority than the rest of the rules in the managed rule sets. Custom rules contain a rule name, rule priority, and a series of corresponding conditions. If these conditions are met, an action is taken (to allow or block).
For example, you can block all requests from an IP address in the 192.168.5.4/24 range. In this rule, the operator is IPMatch , the matchValues is the IP address range (192.168.5.4/24), and the action is to block traffic. You also define the rule name and priority.
Custom rules support using composition logic to create more advanced rules that meet your security needs. For example, ((Condition 1 and Condition 2) or Condition 3). This means that if Condition 1 and Condition 2 are met, or if Condition 3 is met, the WAF must perform the action specified in the custom rule.
Different match conditions within the same rule are always combined using and . For example, block traffic from a specific IP address and only if you are using a certain browser.
If you want to use or between two different conditions, the two conditions must be in different rules. For example, block traffic from a specific IP address, or block traffic if using a specific browser.
NOTE: The maximum number of custom WAF rules is 100.
47 – The Add custom rule screen will open, in Custom rule name select a name for the rule, in Priority enter a value for the priority, in Conditions for the Match type option select Geo location for the Match variable option select RequestMethod, in Operation select Is, in Country/Region select Brazil and for the option Then select Allow traffic. In this rule we are only allowing access to the application in Brazil. For more information about custom rules for Web Application Firewall v2 on Azure Application Gateway, access the link below.
48 – As we can see the rule was created, then click Next: association.
49 – On the Association screen, click on + Add association, we have 3 options available, Application Gateway, HTTP Listener and Routh Path, we will select Application Gateway, the Associate an application gateway screen will open as we already have a WAF policy configured and we are replacing it with this one new it is necessary to select the option Apply the Web Application Firewall policy configuration even if it is different from the current configuration, then click Add.
50 – After adding the policy click on Review + create.
51 – On the Review + create screen, check that all the information filled in is correct and click Create.
52 – Wait for the resource deployment to finish.
53 – As we can see the deployment was finished, click on Go to resource.
54 – If necessary, we can create or modify the existing configurations.
Testing the functionality of the Web Application Firewall
What is XSS Stored Vulnerability?
XSS Stored is the most dangerous cross-site scripting vulnerability. This type of vulnerability arises whenever a web application stores user-provided data for later use in the backend without performing any input filtering or sanitizing. As the web application does not apply any filters, an attacker could inject some malicious code into this input field. This malicious code could also be a valid XSS payload. Therefore, whenever anyone visits the vulnerable page where the malicious code was injected, they will get a pop-up in their browser window. This will prove that the provided webpage is vulnerable to stored XSS vulnerability.
55 – Copy the Public IP of the Application Gateway and paste it in your browser.
56 – Then log in to the application.
57 – On the application screen, click on XSS (Stored).
58 – In Name type test1 for the Message option, type the text below and then click on Sign Guestbook:
59 – After clicking on Sign Guestbook, the WAF blocks the attack, as we can see in the image below.
What is SQL Inject vulnerability
SQL injection is considered a high risk vulnerability due to the fact that it can lead to a complete compromise of the remote system. That's why in almost all web application penetration testing jobs, applications are always checked for SQL injection failures. A General and Simple Definition When an application is vulnerable to SQL injection is when the application allows you to interact with the database and execute queries against the database, then it is vulnerable to SQL injection attacks.
60 – In the application, click on SQL Injection.
61 – We will use the UNION statement to join two queries and be able to discover the database version, type the command below in the application and click Submit.
'union select @@ version #
We can also try to query the available columns of the table using order by syntax, with the following command:
SELECT First_Name, Last_Name FROM users WHERE ID=” sort by 1 #
62 – As we can see, WAF blocked SQL Inject attacks in the application.
Checking the Web Application Firewall logs
63 – In the portal search for Applications gateways, in Applications Gateway select the resource we created.
64 – In Monitoring click on Logs.
65 – Type the query below to bring all the information related to the Application Gateway Firewall, then click Run.
| where ResourceProvider == “MICROSOFT.NETWORK” and Category == “ApplicationGatewayFirewallLog”
66 – In Results in the fields requestUri_s and Message, miss that we have the information of the sqli inject and xss attacks.
Comment on your suggestions and observations!
Big hug, thanks and see you in the next post.
Was this article helpful?
To maintain a quality standard for you, we have invested in a great hosting plan, Paid CDN, Website Optimization Plugins, etc ...
Help us to keep the project active!