After we in our first OWASP Top 10 post 3 Broken Access Control Attacks, we are now talking about injection attacks. In this article, we'll look at implementing a Web Application Firewall (WAF) with NGINX and ModSecurity to Protect websites against the OWASP Top 10 Injection Attacks.
A WAF is a security solution placed between a website and the Internet to protect it from known threats. OWASP Top 10 Injection attacks are one of the most common threats web applications face.
OWASP Top 10 Injection Attacks are a variety of attacks aimed at compromising the integrity of data residing on the web application. Below we present some of the most well-known OWASP top 10 injection attacks.
A SQL injection attack is performed by an attacker sending a malicious SQL query to the web application's database. If the web application has not implemented appropriate protection measures, the attacker can manipulate the database, disclose information and steal it.
LDAP injection attacks are similar to SQL injection attacks, but target the Lightweight Directory Access Protocol (LDAP). With an LDAP injection attack, an attacker can access and manipulate the LDAP directory of the web application.
A command injection attack occurs when an attacker sends a malicious command line to the web application being run by an operating system. If the web application has not implemented appropriate protection measures, the attacker can run arbitrary commands on the affected system.
A WAF works by reading the incoming Monitors web application traffic and applies filters to that traffic. These filters are configured to e.g. B. Detect and block injection input. A WAF can be implemented either in hardware or in software.
NGINX is a popular open source software that is widely used as a reverse proxy and load balancer. For NGINX (Plus) is with the module ModSecurity WAF another open source software available.
NGINX ModSecurity WAF is coming next year though end of life and will only be supported until March 2024. NGINX Plus is also supported.
Implementing a WAF with NGINX Plus and ModSecurity requires 5 Steps, which we describe below.
You can install NGINX Plus on various operating systems, including Linux, Windows and MacOS. The installation of NGINX Plus differs depending on the operating system, but there are numerous guides on the Internet.
ModSecurity is an open-source cross-platform WAF engine and can be integrated as a module in NGINX Plus. Installing ModSecurity may vary depending on the operating system.
After you have installed the module, you need to make sure that it is loaded via the appropriate configuration file: /etc/nginx/nginx.conf
load_module modules/ngx_http_modsecurity_module.so;
NGNIX Plus can be used as Reverse Proxy be configured. To do this, you create a suitable configuration file /etc/nginx/conf.d/proxy.conf. You store the relevant parameters in this file – adapted to your own use case.
server {
listen 80;
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
location / {
proxy_pass http://localhost:8085;
proxy_set_header Host $host;
}
}
Make sure that no other configuration file contains a virtual server Port 80 listens. If this is the case, you have to adapt the corresponding files by commenting out the respective lines of code.
For example, this is in the file /etc/nginx/conf.d/default.conf the case, which is part of the NGINX Plus Package.
In order to allow the filter rules to run, you need to edit the configuration file /etc/nginx/modsec/modsecurity.conf adjust accordingly and turn on the engine.
# SecRuleEngine DetectionOnly
SecRuleEngine On
Then you can come with me /etc/nginx/modsec/main.conf create another configuration file in which the previously adjusted modsecurity.conf is called. You can also activate here the rules for the OWASP Top 10 Injection Attacks:
# Include the recommended configuration
Include /etc/nginx/modsec/modsecurity.conf
# OWASP CRS v3 rules
Include /usr/local/owasp-modsecurity-crs-3.0.2/crs-setup.conf
...
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-912-DOS-PROTECTION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-913-SCANNER-DETECTION.conf
...
The files crs-setup.conf and * .conf contain the rules for protection against the OWASP Top 10 injection attacks. With the OWASP Core Rule Set (CRS), which we use here, ready-made rules are already available.
Of course, it is also possible to configure and integrate your own rules. In this article we explain how to do it: ModSecurity Core Rule Sets and Custom Rules
When using the OWASP CRS, you should note that requests with cross-site scripting (XSS) content are not blocked by default. You must supplement this rule accordingly.
You can check the functionality of the WAF by using a OWASP Top 10 Injection attack against the web application execute If properly configured, the WAF should detect and block the attack. Usually, a post-configuration and adaptation to your own requirements makes sense. Use a vulnerability scanner of your choice (e.g. Nikto) to validate the implemented security measures.
The following examples show what damage OWASP Top 10 Injection attacks can do. By using a WAF, organizations can protect their web applications from a variety of these attacks and keep their customers safe. However, it is important that the WAF is regularly updated and the configured rulesets are expanded. This is the only way to ensure that it is always up to date and able to detect the latest threats.
SELECT * FROM users WHERE username = '$username' AND password = '$password';
An attacker could try to inject this code with a malicious username and password to gain access to the Juice Shop database. Here is an example of malicious input:
' OR '1'='1
The SQL query then looks like this:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '' OR '1'='1';
A WAF can detect this type of attack by scanning the input forms for malicious strings and suspicious keywords.
<div>
<p>Willkommen, $username</p>
</div>
An attacker could try to inject this code with a malicious username to run malicious code on the Juice Shop website. Here is an example of malicious input:
alert('Ich habe den Juice Shop gehackt!');
This would cause the malicious javascript code to run on the Juice Shop website when a user with that username is logged in and visits the page. A WAF can detect this type of attack by examining the input forms for suspicious script tags and malicious strings.
const exec = require('child_process').exec;
const cmd = '$command';
exec(cmd, (error, stdout, stderr) => {
console.log(stdout);
});
An attacker could try to inject this code with a malicious command to take control of the Juice Shop server. Here is an example of malicious input:
const cmd = 'rm -rf /';
This would result in the command rm-rf / running on the Juice Shop's server, which would result in catastrophic data loss. A WAF could detect this type of attack by scanning incoming traffic for suspicious commands and malicious strings.
const path = '/uploads/' + req.query.file;
fs.readFile(path, (err, data) => {
res.send(data);
});
An attacker could try to inject this code with a manipulated query parameters file to access a file that they do not normally have access to. Here is an example of malicious input:
?file=../../../../../etc/passwd
This would cause the attacker to access the file / Etc / passwd can access, which is normally only accessible to the root user. A WAF can detect this type of attack by examining the query parameter files for suspicious patterns and illegal strings.
const xml = `
<!DOCTYPE foo [
]>
&xxe;
`;
parser.parse(xml, (err, result) => {
console.log(result);
});
An attacker could try to inject this code with a malicious XML document to access files on the Juice Shop server. Here is an example of malicious input:
<!DOCTYPE foo [
]>
&xxe;
This would cause the attacker to access the file / Etc / passwd can access, which is normally only accessible to the root user. A WAF can detect this type of attack by examining the XML documents for suspicious patterns and illegal strings.
Here are some of the methods a WAF can use to detect attacks:
Known attack signatures can be stored to detect attacks. These signatures are based on known attack patterns and come from security researchers and other sources relevant to IT security.
A WAF can also monitor user and application behavior to detect anomalies and suspicious activity. For example, if an application suddenly receives a large number of requests from a single IP address, this can be an indicator of an attack.
The reputation of IP addresses and other sources is monitored to detect suspicious activity. For example, if an IP address has been known to attack other web applications in the past, it can be blacklisted accordingly.
Anomalies and suspicious activity can be detected and stored as patterns to identify an attack. The algorithm learns how a normal application behaves and detects anomalies that indicate an attack.
By combining these technologies, a WAF can protect a web application from a variety of threats and ensure the integrity of its data. However, it is important that a WAF is updated regularly to ensure that it is always current and has the latest updates applied.
A WAF can prevent a variety of attacks including SQL injection, LDAP injection, command injection, and many other types of attacks.
A WAF cannot prevent all types of attacks, but it can help minimize the risk of attacks and limit damage when an attack occurs.
By targeting known attacks against the applications. If your WAF is properly configured, it should detect the attack and take appropriate action (like blocking it).
