Over the past few years, web application security
has become a key issue in IT. For companies, system stability is crucial to their reputation and the avoidance of unnecessary costs. Annual statistics from large information security companies indicate an increase in the number and quality of attacks. In an earlier article , I discussed protecting web applications using IDPS-class systems. Today, I'd like to share information on working with a WAF. In this article, I'll begin with theory and move on to configuration. We'll be running two servers, one for attack and the other for protection using a WAF. I hope this article will be an accessible introduction for engineers who haven't previously considered working with a WAF due to its unfamiliarity with this type of system. Interested? Then welcome!
Use the navigation if you don't want to read the full text:
→ Where it all comes from: web service vulnerabilities
→ Introduction to open-appsec
→ Testing open-appsec
→ Conclusions
First, let's define what we'll be working with. As we know, information security incidents follow this chain: System → Intruder → Threat → Vulnerability → Vulnerability Exploitation.
The emergence of a web application vulnerability is usually not a sudden problem, but rather a subtle issue waiting to be discovered. There are several reasons why it occurs.
If the application is monolithic or consists of microservices that are not separated by a DMZ/do not validate transmitted data, then impacting some components will affect the operation of others.
The most common case is a lack of validation of the data being sent. This problem can lead to a wide range of injections—essentially, to any imaginable outcome.
Untrustworthy employees/partners can also cause vulnerabilities in service components. There are even "Blockbuster" stories where particularly sophisticated hacktivists, guided by the principle of "Keep your friends close, but your enemies closer," infiltrate an organization and deliberately cause harm.
Developing applications without industry best practices, taking into account previous experience, or vendor recommendations can significantly reduce the information security level of the future application. It's advisable to have an expert on hand at all times—or outsource it .
Adding static and dynamic code analysis tools to your pipeline will definitely be beneficial. Moreover, it will help identify potential security issues before publishing the service.
You can write a fairly secure application, but misconfigure the environment or fail to patch services in a timely manner. This will lead to exploitation of vulnerabilities. The posts at https://www.exploit-db.com/ confirm this.
Attacks like SSRF can easily overtake your application if you handle requests to third-party resources without proper validation. On your end, exploits may appear as legitimate requests and not be blocked by any components.
As you can see, the above-mentioned vulnerability causes give rise to all the hacking methods found in the OWASP rankings. Of course, it's impossible to control everything. Sooner or later, a vulnerability will appear at some point, waiting for its—at best—bug hunter. What to do? Spoiler alert: use a WAF!
The evolution of WAFs is usually described in three generations:
1. WAFs based on regular expressions,
2. WAFs with special expressions (tokens) for each type of attack,
3. WAFs based on machine learning methods.
There's a wealth of information online about popular open-source WAF systems. There are quite a few solutions, including ModSecurity, Coraza, IronBee, WebKnight, Shadow Daemon, OctopusWAF, and others. Some of these solutions haven't had their repositories updated in a while, but they're still actively used to protect a large number of web applications.
ModSecurity has been the most widely written about, so in this article, we'll look at one of the interesting alternatives: open-appsec from CheckPoint. Incidentally, this is a third-generation WAF technology: it uses an ML engine, which allows for quite effective protection with a minimal barrier to entry. So, sit back and relax.
The core functionality of open-appsec—a community version based on three WAG agents—is available for free and is well suited for protecting small web services. The solution is available for deployment in one of three scenarios: Kubernetes Ingress, Nginx Add-On, or Kong API Gateway Add-On—and is managed via a configuration file or a web portal .
Using a configuration file ensures complete autonomy, while the portal provides a user-friendly control panel and dashboards out of the box. Incidentally, a Google or GitHub account is sufficient for portal authorization. The community version includes the following security components:
The following control options are also available:
In this case, support is limited to the forum, but you can study the WAF deployment instructions for various scenarios and configurations for free. Detailed instructions are available in the official documentation .
In this article, we'll look at how to improve the security of a web application using open-appsec. We'll deploy the vulnerable system in a Docker container using the repository , and the WAF on a separate virtual machine with Nginx installed. The attacker will be hosted on a separate server.
We'll use OWASP JuiceShop as the vulnerable web application. It's an excellent "colander" for testing, as it already contains vulnerabilities in the XSS, CSRF, SSRF, SSTI, XXE, SQL Injection, and other categories.
Creating a virtual machine
: 1. Log in to the my.selectel.ru control panel . From the Cloud Platform , navigate to Servers and click Create server . Configure the configuration to complete server creation.
2. Copy the server's IP address and password, connect via SSH, install Docker, and deploy the Docker image:
apt install docker.io -y
docker pull bkimminich/juice-shop
3. Let's launch the container, specifying the application access port 8080, and check the availability of the web application:
docker run --rm -p 8080:3000 bkimminich/juice-shop
curl http://localhost:8080
Creating an attacker host:
1. Log into the my.selectel.ru control panel . From the Cloud Platform , navigate to Images and click Create Image . Select Kali Linux, installed from the official website , as the image —it has all the necessary tools.
2. From the Cloud Platform , go to Servers and click Create Server . Select the uploaded image as the operating system:
Setting up a cloud firewall
. A vulnerable application has been published. To prevent anyone but us from hacking it, we'll restrict internet access using a cloud firewall. The solution is free for all cloud platform users.
1. Log in to the my.selectel.ru control panel . From the Cloud Platform, go to Firewalls and click Create Firewall . 2. Add Inbound traffic
rules to restrict access to the testbed. Allow connections only from trusted white IP addresses and reject all other requests.
Incoming traffic rules.
3. Only the NAT network in which the booth hosts are located is allowed to access the internet.
Outgoing traffic rules.
Great—the setup is ready, we'll install the WAF later.
Now I'll show you how to exploit web application vulnerabilities included in the OWASP Top 10. JuiceShop has a section with a list of vulnerabilities—you can find it at /score-board.
The section with the list of vulnerabilities.
I'll take three tasks with different types of vulnerabilities and apply them to the application.
1. DOM XSS. In the search field, add an iframe tag with an alert:
<iframe src=”javascript”:alert(‘xss!’)”>
We see that XSS is indeed present and ready for exploitation.
2. Login Admin. In the login form, we'll write a simple SQL injection to bypass authorization and log in as the administrator. As we can see, this wasn't particularly difficult:
3. Password Strength. Next, let's try logging in as the administrator without using injections—obviously, we'll need to brute-force the password. In Burpsuite, I intercept the login attempt and send it to Intruder:
I set the email parameter to [email protected], and I'll brute-force the password with a list of passwords . The value admin123 worked, allowing me to log in as an admin without injections:
As we can see, the application is breaking. Now we need to take steps to close these vulnerabilities using a WAF.
The hacking techniques are clear. Let's imagine that the application developers, for obvious reasons, haven't patched the vulnerabilities, and the application can't be left in this state. In this case, open-asspec will help.
1. Similar to the application host, go to the my.selectel.ru control panel . From the Cloud Platform , go to Servers and click Create Server . Configure the configuration to complete the server creation.
2. Copy the server's IP address and password, connect via SSH. Install nginx:
apt install nginx -y
3. Publish the application via nginx. To do this, create a juiceshop.conf file and add the following configuration:
nano /etc/nginx/sites-available/juiceshop.conf
server {
listen 80;
server_name juiceshop.test;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://192.168.0.3:8080
}
location ~ /\. {
deny all;
}
}
4. Create a link to the configuration and install the open-appsec agent:
ln -s /etc/nginx/sites-available/juiceshop.conf /etc/nginx/sites-enabled/juiceshop.conf
wget https://downloads.openappsec.io/open-appsec-install && chmod +x open-appsec-install
open-appsec for NGINX, Kong and APISIX Installer v1.2245.1
For release notes and known limitations check:
docs.openappsec.io
Searching local NGINX…
nginx version found: 1.18.0-0ubuntu1.4
Downloading open-appsec NGINX attachment... stored in '/tmp/open-appsec'
Downloading open-appsec agent... stored in '/tmp/open-appsec'
Add your email to receive important security updates and so you can approach us with technical questions (enter IGNORE to ignore):
IGNORE
Installing open-appsec for NGINX...
Updating NGINX server configuration...
Starting open-appsec installation...
Successfully installed open-appsec...
For release notes and known limitations check: https://docs.openappsec.io/release-notes
For troubleshooting and support: https://openappsec.io/support
Now the open-appsec agent directories and files are accessible from /etc/cp/.
5. Next, you need to connect open-appsec to the portal. To do this, log in to the portal at https://www.openappsec.io and create an agent. Go to Getting Started , and in the Central Management section , select " Managed → Linux Embedded Agent Profile ." Enter "Test Agent" as the name, set "Manual" to "Agent Upgrade ," and select "NGINX application security" for Deployment :
6. In the Management section, select "This management" as the method for setting policies and defining agents. Then, on the Nginx virtual machine, run two commands to connect the agent to the portal:
Uploading local policy configuration to cloud...
...
Registering open-appsec Nano Agent to Fog..
open-appsec Nano Agent is registered to https://inext-agents.cloud.ngen.checkpoint.com
Orchestration mode changed successfully
If everything went well, you'll receive a notification like this, and the Agents section will contain information about the instance:
Notification.
Instance information.
6. Next, enable log sending to the portal. A new resource appears in the Assets section after connecting the agent. Go to its properties. The linked profile is visible in General → Basic :
In General → Web Application , it is specified that the agent will pass traffic to all resources published via HTTP:
In General → Source Identity and Trusted Sources, you can change the methods for determining connection sources to protected resources, as well as specify trusted sources:
In the Threat Prevention section , you can manage application protection components by specifying learning/detection or prevention mode. We'll leave everything in learning mode initially, and then change it to prevention. The Learn
section currently shows that there has been no traffic yet. In Rate Limit , you can set bandwidth limits for accessing the protected application, and in Triggers , a policy was created after connecting the agent. WAF training is performed using an ML model, which is available in Account → Download advanced ML model . If you need to add custom rules, you can do so in Assets → Custom rules and exceptions . Important: APIs can also be protected by creating separate resources in the Assets section . 7. Apply the policy to the agent. In the Behaviors section , you can configure custom response pages when access to the protected resource is denied by the open-appsec agent. In this policy, we enable sending logs to the portal, as well as advanced logging of URL path, URL query, HTTP headers, and Request body.
8. Scan the application using scanners in Kali Linux.
Now you can access the vulnerable application from the Kali virtual machine in two ways: directly at http://192.168.0.3:8080 or through nginx with open-appsec ( http://juiceshop.test ).
To train the WAF, you need to generate different types of traffic. To do this, add the following entry to /etc/hosts on the Kali virtual machine:
192.168.0.100 juiceshop.test
Let's run a scan using nikto, an example of which I wrote about earlier in the article :
nikto -h http://juiceshop.test –output report.html
A message about the resource's start of training should appear in the web panel:
You can track your progress in the Assets → Learn section . The ML engine training process itself is described in detail on the open-appsec website .
Additionally, we'll generate traffic using nmap and skipfish:
nmap -sV --script=http-enum juiceshop.test
skipfish -o res http://juiceshop.test
Meanwhile, during the scan, JuiceShop reports the successful completion of the tasks:
Next, I'll run a scan using the wonderful commix tool:
The same can be done from the console:
commix -u http://juiceshop.test --level 3
As a result, the WAF has certain statistics that can be further developed:
It's time to repeat the same attacks on the trained WAF. First, in the Assets → Threat Prevention section , switch the mode from Learn/Detect to Prevent for the Web Attacks and Intrusion Prevention parameters . Next, apply the policy and re-attack the test application via http://juiceshop.test and observe the results.
1. DOM XSS. The WAF detects XSS in the POST request:
2. Login Admin. Repeated attempts to bypass authorization are unsuccessful, and the following events have appeared in the Monitoring section:
The incident card contains a lot of useful information, including the source, the payload used, and the attack indicator that was triggered:
Attempts to bypass the WAF using alternative requests are also blocked:
Attempts to transmit payloads in BASE-64 are also blocked. The WAF decodes the payload and also detects the attack:
Open-appsec periodically requests clarification on whether requests from sources are classified as legitimate or malicious activity:
This allows for more efficient training with fewer false positives.
3. Password Strength. To prevent brute-force attacks, you can, for example, create a rule in the Rate Limit section:
For clarity, I'll run a rescan using Commix with the WAF running in Prevent mode. If I sniff incoming traffic on the interfaces of the server running the WAF and the server running the containerized application, I'll see that ARP requests aren't reaching the second host.
You can view statistics on repelled attacks in the Monitoring section of the portal :
As I mentioned above, you can find detailed information about the source, attack type, and payload used for each event. You can also manage the agent locally. Here are a few commands.
Viewing the policy:
open-appsec-ctl -vp
View logs:
open-appsec-ctl -vl
Great—the out-of-the-box WAF detects and mitigates attacks after a short training period (without high-quality signatures). But let's try bypassing it using waf-bypass .
1. Clone the repository and run the solution locally on Kali Linux:
# git clone https://github.com/nemesida-waf/waf_bypass.git /opt/waf-bypass/
# python3 -m pip install -r /opt/waf-bypass/requirements.txt
# python3 /opt/waf-bypass/main.py --host='example.com'
2. Launch waf-bypass:
python3 /opt/waf-bypass/main.py –host=’juiceshop.test’
3. We will conduct testing in two stages: Learn/Detect and Prevent modes.
Learn/Detect Test.
Prevent test.
As you can see, there is some result, but it's not 100%. To fix this, you can switch to an advanced AI model , continue training the model, or add custom rules.
As we can see, the open-appsec WAF doesn't guarantee 100% success out of the box, but it significantly improves the application's security. In most cases, the solution will address web application security flaws, but you can't afford to relax and neglect the architecture.
Open-appsec can add a fairly robust security layer with minimal effort. However, for more effective protection, fine-tuning is required, taking into account the set of allowed requests for your service.
has become a key issue in IT. For companies, system stability is crucial to their reputation and the avoidance of unnecessary costs. Annual statistics from large information security companies indicate an increase in the number and quality of attacks. In an earlier article , I discussed protecting web applications using IDPS-class systems. Today, I'd like to share information on working with a WAF. In this article, I'll begin with theory and move on to configuration. We'll be running two servers, one for attack and the other for protection using a WAF. I hope this article will be an accessible introduction for engineers who haven't previously considered working with a WAF due to its unfamiliarity with this type of system. Interested? Then welcome!
Use the navigation if you don't want to read the full text:
→ Where it all comes from: web service vulnerabilities
→ Introduction to open-appsec
→ Testing open-appsec
→ Conclusions
Where the roots come from: web service vulnerabilities
First, let's define what we'll be working with. As we know, information security incidents follow this chain: System → Intruder → Threat → Vulnerability → Vulnerability Exploitation.
- The system is our potential web application.
- The offender is the criminal.
- A threat is the potential for harm to our system.
- A vulnerability is a flaw in a system that can be exploited to implement a threat.
- Vulnerability exploitation is the use of an exploit to implement a threat.
The emergence of a web application vulnerability is usually not a sudden problem, but rather a subtle issue waiting to be discovered. There are several reasons why it occurs.
Reason 1. Poor application architecture
If the application is monolithic or consists of microservices that are not separated by a DMZ/do not validate transmitted data, then impacting some components will affect the operation of others.
Reason 2. The architecture simply does not take information security issues into account
The most common case is a lack of validation of the data being sent. This problem can lead to a wide range of injections—essentially, to any imaginable outcome.
Reason 3. Intentional introduction of vulnerabilities
Untrustworthy employees/partners can also cause vulnerabilities in service components. There are even "Blockbuster" stories where particularly sophisticated hacktivists, guided by the principle of "Keep your friends close, but your enemies closer," infiltrate an organization and deliberately cause harm.
Reason 4. Insufficient competencies in the technology stack
Developing applications without industry best practices, taking into account previous experience, or vendor recommendations can significantly reduce the information security level of the future application. It's advisable to have an expert on hand at all times—or outsource it .
Reason 5. Poor and insufficient tests
Adding static and dynamic code analysis tools to your pipeline will definitely be beneficial. Moreover, it will help identify potential security issues before publishing the service.
Reason 6. Vulnerabilities in third-party services
You can write a fairly secure application, but misconfigure the environment or fail to patch services in a timely manner. This will lead to exploitation of vulnerabilities. The posts at https://www.exploit-db.com/ confirm this.
Reason 7. Vulnerabilities in third-party services
Attacks like SSRF can easily overtake your application if you handle requests to third-party resources without proper validation. On your end, exploits may appear as legitimate requests and not be blocked by any components.
As you can see, the above-mentioned vulnerability causes give rise to all the hacking methods found in the OWASP rankings. Of course, it's impossible to control everything. Sooner or later, a vulnerability will appear at some point, waiting for its—at best—bug hunter. What to do? Spoiler alert: use a WAF!
WAF as a protector against vulnerability exploitation
The evolution of WAFs is usually described in three generations:
1. WAFs based on regular expressions,
2. WAFs with special expressions (tokens) for each type of attack,
3. WAFs based on machine learning methods.
Introduction to open-appsec
There's a wealth of information online about popular open-source WAF systems. There are quite a few solutions, including ModSecurity, Coraza, IronBee, WebKnight, Shadow Daemon, OctopusWAF, and others. Some of these solutions haven't had their repositories updated in a while, but they're still actively used to protect a large number of web applications.
ModSecurity has been the most widely written about, so in this article, we'll look at one of the interesting alternatives: open-appsec from CheckPoint. Incidentally, this is a third-generation WAF technology: it uses an ML engine, which allows for quite effective protection with a minimal barrier to entry. So, sit back and relax.
The core functionality of open-appsec—a community version based on three WAG agents—is available for free and is well suited for protecting small web services. The solution is available for deployment in one of three scenarios: Kubernetes Ingress, Nginx Add-On, or Kong API Gateway Add-On—and is managed via a configuration file or a web portal .
Using a configuration file ensures complete autonomy, while the portal provides a user-friendly control panel and dashboards out of the box. Incidentally, a Google or GitHub account is sufficient for portal authorization. The community version includes the following security components:
- Web Application Attack Mitigation (ML-based WAF),
- Web API Attack Mitigation (ML-based WAF),
- IPS Engine with Snort 3.0 Support,
- Rate Limiting,
- Custom Source Identifiers (IP and XFF only).
The following control options are also available:
- Declarative code based deployment and configuration (DevOps style),
- Web-based Management of Protected Assets & Policy (SaaS),
- Web-based Event Management & Dashboards (SaaS),
- Log Storage in the Cloud.
In this case, support is limited to the forum, but you can study the WAF deployment instructions for various scenarios and configurations for free. Detailed instructions are available in the official documentation .
Open-appsec testing
Preparing the target scheme
In this article, we'll look at how to improve the security of a web application using open-appsec. We'll deploy the vulnerable system in a Docker container using the repository , and the WAF on a separate virtual machine with Nginx installed. The attacker will be hosted on a separate server.
We'll use OWASP JuiceShop as the vulnerable web application. It's an excellent "colander" for testing, as it already contains vulnerabilities in the XSS, CSRF, SSRF, SSTI, XXE, SQL Injection, and other categories.
Creating a virtual machine
: 1. Log in to the my.selectel.ru control panel . From the Cloud Platform , navigate to Servers and click Create server . Configure the configuration to complete server creation.
2. Copy the server's IP address and password, connect via SSH, install Docker, and deploy the Docker image:
apt install docker.io -y
docker pull bkimminich/juice-shop
3. Let's launch the container, specifying the application access port 8080, and check the availability of the web application:
docker run --rm -p 8080:3000 bkimminich/juice-shop
curl http://localhost:8080
Creating an attacker host:
1. Log into the my.selectel.ru control panel . From the Cloud Platform , navigate to Images and click Create Image . Select Kali Linux, installed from the official website , as the image —it has all the necessary tools.
2. From the Cloud Platform , go to Servers and click Create Server . Select the uploaded image as the operating system:
Setting up a cloud firewall
. A vulnerable application has been published. To prevent anyone but us from hacking it, we'll restrict internet access using a cloud firewall. The solution is free for all cloud platform users.
1. Log in to the my.selectel.ru control panel . From the Cloud Platform, go to Firewalls and click Create Firewall . 2. Add Inbound traffic
rules to restrict access to the testbed. Allow connections only from trusted white IP addresses and reject all other requests.
Incoming traffic rules.
3. Only the NAT network in which the booth hosts are located is allowed to access the internet.
Outgoing traffic rules.
Great—the setup is ready, we'll install the WAF later.
Analysis of application hacking techniques
Now I'll show you how to exploit web application vulnerabilities included in the OWASP Top 10. JuiceShop has a section with a list of vulnerabilities—you can find it at /score-board.
The section with the list of vulnerabilities.
I'll take three tasks with different types of vulnerabilities and apply them to the application.
1. DOM XSS. In the search field, add an iframe tag with an alert:
<iframe src=”javascript”:alert(‘xss!’)”>
We see that XSS is indeed present and ready for exploitation.
2. Login Admin. In the login form, we'll write a simple SQL injection to bypass authorization and log in as the administrator. As we can see, this wasn't particularly difficult:
3. Password Strength. Next, let's try logging in as the administrator without using injections—obviously, we'll need to brute-force the password. In Burpsuite, I intercept the login attempt and send it to Intruder:
I set the email parameter to [email protected], and I'll brute-force the password with a list of passwords . The value admin123 worked, allowing me to log in as an admin without injections:
As we can see, the application is breaking. Now we need to take steps to close these vulnerabilities using a WAF.
Setting up a WAF for protection
The hacking techniques are clear. Let's imagine that the application developers, for obvious reasons, haven't patched the vulnerabilities, and the application can't be left in this state. In this case, open-asspec will help.
1. Similar to the application host, go to the my.selectel.ru control panel . From the Cloud Platform , go to Servers and click Create Server . Configure the configuration to complete the server creation.
2. Copy the server's IP address and password, connect via SSH. Install nginx:
apt install nginx -y
3. Publish the application via nginx. To do this, create a juiceshop.conf file and add the following configuration:
nano /etc/nginx/sites-available/juiceshop.conf
server {
listen 80;
server_name juiceshop.test;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://192.168.0.3:8080
}
location ~ /\. {
deny all;
}
}
4. Create a link to the configuration and install the open-appsec agent:
ln -s /etc/nginx/sites-available/juiceshop.conf /etc/nginx/sites-enabled/juiceshop.conf
wget https://downloads.openappsec.io/open-appsec-install && chmod +x open-appsec-install
open-appsec for NGINX, Kong and APISIX Installer v1.2245.1
For release notes and known limitations check:
Release Notes | open-appsec
docs.openappsec.io
nginx version found: 1.18.0-0ubuntu1.4
Downloading open-appsec NGINX attachment... stored in '/tmp/open-appsec'
Downloading open-appsec agent... stored in '/tmp/open-appsec'
Add your email to receive important security updates and so you can approach us with technical questions (enter IGNORE to ignore):
IGNORE
Installing open-appsec for NGINX...
Updating NGINX server configuration...
Starting open-appsec installation...
Successfully installed open-appsec...
For release notes and known limitations check: https://docs.openappsec.io/release-notes
For troubleshooting and support: https://openappsec.io/support
Now the open-appsec agent directories and files are accessible from /etc/cp/.
5. Next, you need to connect open-appsec to the portal. To do this, log in to the portal at https://www.openappsec.io and create an agent. Go to Getting Started , and in the Central Management section , select " Managed → Linux Embedded Agent Profile ." Enter "Test Agent" as the name, set "Manual" to "Agent Upgrade ," and select "NGINX application security" for Deployment :
6. In the Management section, select "This management" as the method for setting policies and defining agents. Then, on the Nginx virtual machine, run two commands to connect the agent to the portal:
Uploading local policy configuration to cloud...
...
Registering open-appsec Nano Agent to Fog..
open-appsec Nano Agent is registered to https://inext-agents.cloud.ngen.checkpoint.com
Orchestration mode changed successfully
If everything went well, you'll receive a notification like this, and the Agents section will contain information about the instance:
Notification.
Instance information.
6. Next, enable log sending to the portal. A new resource appears in the Assets section after connecting the agent. Go to its properties. The linked profile is visible in General → Basic :
In General → Web Application , it is specified that the agent will pass traffic to all resources published via HTTP:
In General → Source Identity and Trusted Sources, you can change the methods for determining connection sources to protected resources, as well as specify trusted sources:
In the Threat Prevention section , you can manage application protection components by specifying learning/detection or prevention mode. We'll leave everything in learning mode initially, and then change it to prevention. The Learn
section currently shows that there has been no traffic yet. In Rate Limit , you can set bandwidth limits for accessing the protected application, and in Triggers , a policy was created after connecting the agent. WAF training is performed using an ML model, which is available in Account → Download advanced ML model . If you need to add custom rules, you can do so in Assets → Custom rules and exceptions . Important: APIs can also be protected by creating separate resources in the Assets section . 7. Apply the policy to the agent. In the Behaviors section , you can configure custom response pages when access to the protected resource is denied by the open-appsec agent. In this policy, we enable sending logs to the portal, as well as advanced logging of URL path, URL query, HTTP headers, and Request body.
8. Scan the application using scanners in Kali Linux.
Now you can access the vulnerable application from the Kali virtual machine in two ways: directly at http://192.168.0.3:8080 or through nginx with open-appsec ( http://juiceshop.test ).
To train the WAF, you need to generate different types of traffic. To do this, add the following entry to /etc/hosts on the Kali virtual machine:
192.168.0.100 juiceshop.test
Let's run a scan using nikto, an example of which I wrote about earlier in the article :
nikto -h http://juiceshop.test –output report.html
A message about the resource's start of training should appear in the web panel:
You can track your progress in the Assets → Learn section . The ML engine training process itself is described in detail on the open-appsec website .
Additionally, we'll generate traffic using nmap and skipfish:
nmap -sV --script=http-enum juiceshop.test
skipfish -o res http://juiceshop.test
Meanwhile, during the scan, JuiceShop reports the successful completion of the tasks:
Next, I'll run a scan using the wonderful commix tool:
The same can be done from the console:
commix -u http://juiceshop.test --level 3
As a result, the WAF has certain statistics that can be further developed:
Re-testing of vulnerability exploitation
It's time to repeat the same attacks on the trained WAF. First, in the Assets → Threat Prevention section , switch the mode from Learn/Detect to Prevent for the Web Attacks and Intrusion Prevention parameters . Next, apply the policy and re-attack the test application via http://juiceshop.test and observe the results.
1. DOM XSS. The WAF detects XSS in the POST request:
2. Login Admin. Repeated attempts to bypass authorization are unsuccessful, and the following events have appeared in the Monitoring section:
The incident card contains a lot of useful information, including the source, the payload used, and the attack indicator that was triggered:
Attempts to bypass the WAF using alternative requests are also blocked:
Attempts to transmit payloads in BASE-64 are also blocked. The WAF decodes the payload and also detects the attack:
Open-appsec periodically requests clarification on whether requests from sources are classified as legitimate or malicious activity:
This allows for more efficient training with fewer false positives.
3. Password Strength. To prevent brute-force attacks, you can, for example, create a rule in the Rate Limit section:
Collecting statistics on repelled attacks
For clarity, I'll run a rescan using Commix with the WAF running in Prevent mode. If I sniff incoming traffic on the interfaces of the server running the WAF and the server running the containerized application, I'll see that ARP requests aren't reaching the second host.
You can view statistics on repelled attacks in the Monitoring section of the portal :
As I mentioned above, you can find detailed information about the source, attack type, and payload used for each event. You can also manage the agent locally. Here are a few commands.
Viewing the policy:
open-appsec-ctl -vp
View logs:
open-appsec-ctl -vl
WAF bypass testing
Great—the out-of-the-box WAF detects and mitigates attacks after a short training period (without high-quality signatures). But let's try bypassing it using waf-bypass .
1. Clone the repository and run the solution locally on Kali Linux:
# git clone https://github.com/nemesida-waf/waf_bypass.git /opt/waf-bypass/
# python3 -m pip install -r /opt/waf-bypass/requirements.txt
# python3 /opt/waf-bypass/main.py --host='example.com'
2. Launch waf-bypass:
python3 /opt/waf-bypass/main.py –host=’juiceshop.test’
3. We will conduct testing in two stages: Learn/Detect and Prevent modes.
Learn/Detect Test.
Prevent test.
As you can see, there is some result, but it's not 100%. To fix this, you can switch to an advanced AI model , continue training the model, or add custom rules.
Conclusions
As we can see, the open-appsec WAF doesn't guarantee 100% success out of the box, but it significantly improves the application's security. In most cases, the solution will address web application security flaws, but you can't afford to relax and neglect the architecture.
Open-appsec can add a fairly robust security layer with minimal effort. However, for more effective protection, fine-tuning is required, taking into account the set of allowed requests for your service.
