WAF attack and defense practice
On July 10, 2013, 5146 words of web security were watched 57778 times+
abstract
This paper is mainly divided into four parts. First, it gives a brief introduction to WAF, so that readers can have a general understanding of such products as WAF. Second, this part demonstrates how to use WAF to provide security protection function for its back-end web applications through an example. Third, security is opposite, no security product in the world can provide 100% security protection function, and WAF also can not provide 100% security protection function It's the same. Therefore, the third part mainly discusses the security of WAF, introduces some mainstream WAF bypass technologies, and demonstrates how to try to bypass the protection of WAF and successfully attack its back-end web applications with a real case; fourth, this part summarizes the security of WAF, and tells readers how to use a correct and rational perspective to see WAF products.
1. Introduction to WAF
The Chinese name of WAF (Web Application Firewall) is called "Web Application Firewall". Using an internationally recognized term, the definition of WAF is as follows: Web application firewall is a product that provides special protection for web applications by implementing a series of security policies for HTTP / HTTPS. From the above definition of WAF, we can clearly understand that WAF is a product that works in the application layer and provides security protection for web applications through specific security policies.
According to different classification methods, WAF can be divided into many kinds. In terms of product form, WAF is mainly divided into the following three categories:
1.1 hardware equipment
At present, most WAFS in the security market belong to this category. They exist in the form of an independent hardware device and support deployment to the network in various ways (such as transparent bridge mode, bypass mode, reverse proxy, etc.) to provide security protection for back-end web applications. Compared with the WAF of software products, the advantages of this kind of products are good performance, comprehensive functions, support for multiple mode deployment, etc., but its price is usually more expensive. WAF produced by domestic manufacturers such as green alliance, Anheng, Qiming star, etc. belong to this category.
1.2 software products
This kind of WAF is realized by pure software, which is characterized by simple installation, easy to use and low cost. But its disadvantages are also obvious, because it must be installed on the web application server, in addition to performance limitations, there may be compatibility, security and other issues. This kind of WAF is represented by ModSecurity, naxsi, website security dog, etc.
1.3 cloud based WAF
With the rapid development of cloud computing technology, it is possible to realize its WAF in the cloud. The safety treasure and 360 website treasure of domestic Innovation workshop are typical representatives of this kind of WAF. Its advantages are rapid deployment, zero maintenance and low cost. It is very attractive for small and medium-sized enterprises and individual webmasters.
2. Using WAF to provide protection for web application
Here, we take naxsi as an example to demonstrate how to use WAF to provide security protection for its back-end web applications. Naxsi is an open source, efficient and low maintenance rule of nginx web application firewall module. The main goal of naxsi is to help people consolidate their web applications against SQL injection, cross site scripting, cross domain forgery requests, local and remote file inclusion vulnerabilities. See http://code.google.com/p/naxsi/wiki/tableofcontents? TM = 6 for details
, because of the space, we will not introduce it in detail. Here we mainly demonstrate the installation, configuration and protection effect of naxsi.
2.1 deployment architecture:
2.1.1 configure nginx as a reverse proxy; let the traffic to the back-end web server pass through nginx
2.1.2 let nasxi (WAF) detect the traffic passing through nginx, block the attack traffic according to the relevant configuration, so as to protect the application running on the back-end web server.
The processing flow of user normal access request is as follows:
Figure 1
The attacker's malicious request processing flow is as follows:
Figure 2
2.2 nginx + naxsi installation
Installation kit:
Nginx 1.3.15：http://nginx.org/download/nginx-1.3.15.tar.gz
Naxsi 0.50：http://naxsi.googlecode.com/files/naxsi-core-0.50.tgz
pcre-8.32：http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download
Installation process:
Install necessary support components
Before installing nginx, you need to install the necessary support components, otherwise nginx cannot be installed normally.
To install PCRE:
[[email protected] LNMP]# wget http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download
[[email protected] LNMP]#tar -zxvf pcre-8.32.tar.gz
[[email protected] nginx-1.3.15]#cd pcre-8.32
[[email protected] pcre-8.32]]#./configure
[[email protected] pcre-8.32]#make && make install
To install the zlib library components:
[[email protected] LNMP]# yum -y install zlib-devel
Nginx and naxsi installation process
[[email protected] LNMP]# wget http://nginx.org/download/nginx-1.3.15.tar.gz
[[email protected] LNMP]# wget http://naxsi.googlecode.com/files/naxsi-core-0.50.tgz
[[email protected] LNMP]# tar -zxvf nginx-1.3.15.tar.gz
[[email protected] LNMP]# tar -zxvf naxsi-core-0.50.tgz
[[email protected] LNMP]# cd nginx-1.3.15
[[email protected] nginx-1.3.15]# ./configure --add-module=../naxsi-core-0.50/naxsi_src
[[email protected] nginx-1.3.15]#make && make install
Start nginx and test
/Usr / local / nginx / SBIN / nginx ා start nginx
/Usr / local / nginx / SBIN / nginx - t ා test whether the configuration file is normal
Kill - 9 nginx - kill nginx process
Kill - HUP ` cat / usr / local / www / nginx / logs / nginx. PID `, restart nginx in a smooth way
Figure 3
If the following error occurs when starting nginx:
Figure 4
Follow the steps below.
32-bit system [root @ localhost lib] ා ln - S / usr / local / lib / libpcre.so.1 / lib64 bit system [root @ localhost lib] # ln - S / usr / local / lib / libpcre.so.1 / lib64
2.3 configuration process:
This specific configuration is divided into two processes: first, modify the nginx.conf configuration file to configure the related options with naxsi (WAF); second, configure nginx as a reverse proxy to provide protection for the back-end web server.
2.3.1 configure naxsi correlation
First, copy the core configuration rule library of naxsi to the directory where the nginx file is located,
Figure 5
Next, modify the nginx.conf configuration file to include the core rule library file of naxsi with the following line:
Figure 6
Then define the security rules of a virtual host. Refer to the following:
LearningMode; #Enables learning mode
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl "/RequestDenied";
include "/tmp/naxsi_rules.tmp";
## check rules
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;
Save the above content in a file. For example, test.rules. We will use it next.
Customize a blocking page. When WAF detects an attack, it will return the page to the user. Please refer to the following:
<html>
<head>
<title>Error 403 Request Denied</title>
</head>
<body>
<h2>Error 403 Request Denied</h2>
For some reasons, your request has been denied.
</body>
</html>
2.3.2 configure reverse agent
Create a new configuration file for the virtual host, as shown in the following figure:
Figure 7
Finally, modify nginx.conf again to include the virtual host configuration file just defined.
Figure 8
The configuration takes effect after the nginx service is restarted.
2.4 demonstration of protection effect
When WAF is not used, it does not have attack protection capability.
Figure 9
Figure 10
Figure 11
After using WAF, the malicious attack is blocked.
Figure 12
Figure 13
Figure 14
3. WAF safety introduction
As a security product, WAF provides security protection for web applications, which can increase the attack difficulty and cost of attackers. However, WAF is not omnipotent. There is no safety product in the world that can provide 100% safety protection. Because of the design or implementation principle of the product, and other problems, attackers can successfully bypass the protection of WAF to attack back-end web applications. In addition to the security of WAF itself, the most discussed is the bypass technology of WAF. Before introducing the technology of WAF bypass, we have to figure out a problem, which is why there is the risk of WAF being bypassed? This is because there is a difference between WAF's parsing of packets and web server's parsing of packets, so it is possible to be bypassed. Here are some of the main WAF bypass technologies in SQL injection:
1. Convert character case
2. Use notes to bypass
3. Code character bypass
4. Separate override character bypass
5. Use truncated characters to bypass
6. Change variable position bypass
7. Proximity for domain name protection
8. Large packet bypass
9. Transfer data submission method bypass
10. HPP (HTTP parameter pollution) bypass
These WAF bypass technologies listed above all have corresponding detailed introduction on the Internet. Because of the space relationship, they will not be introduced here. Interested readers can search relevant materials by themselves. Let's introduce the bypass of WAF through a real case.
Example of WAF bypass technology
In a WAF bypass activity held by the safety treasure some time ago, the white hats successfully bypassed the WAF of the safety treasure through various skills. Here's a WAF bypass technique I found:
Background:
In front of a web application with SQL injection vulnerability, the security treasure cloud WAF is deployed. The traffic to visit the web application first passes through the WAF, and the WAF detects whether there is an attack. If the WAF detects a malicious attack, it will return a specific blocking page to the attacker. Otherwise, the normal page will be returned.
1. First, the classic "and 1 = 1" is used to determine whether the web application has SQL injection vulnerability. Because the front end is protected by WAF, normally the request should be blocked by WAF. As expected, when we send a request with attack characteristics, the WAF is blocked and a 405 error page is returned.
Figure 15
2. Now we try to convert get request to post, and bring attack string in post request to judge whether it is intercepted by WAF. What's the result? See the figure below:
Figure 16
3. From the figure above, we can see that the request is not intercepted by WAF, but returned to the normal web application page. It shows that we have successfully bypassed the WAF. However, to this end, we only confirm that the web application has SQL injection vulnerability. Then let's try to construct SQL statements to extract the relevant information of the web application database. The results are as follows:
Figure 17
4. Through the above test, we can confirm that after the get request is converted to post, we can successfully bypass the detection of WAF and obtain the relevant information and data of the target web application. Other WAFS may have the same problem.
4, summary
Through the above introduction and the corresponding example demonstration, I believe that readers have a more comprehensive understanding of WAF. So what should we think of WAF products? There are two kinds of extreme understandings that are wrong. 1. After deploying WAF, you can have peace of mind and don't have to worry about security issues anymore; 2. WAF is useless, because it may be bypassed.
Why are these two understandings wrong? First of all, as a security product, WAF protects against general-purpose attacks and usually acts as a virtual patch. There are also different WAFS from different manufacturers in terms of performance and protection ability due to implementation principle, technical ability, model and other reasons, which cannot be generalized. It is undeniable that WAF can defend most conventional attacks and block a large number of attackers. Otherwise, WAF has no value. But for some attackers with strong technical ability, WAF can not stop them from attacking. They have the ability to bypass WAF to successfully carry out attacks. For the second point, as we have said before, safety is relative. There is no safety product in the world that can provide 100% safety protection. Therefore, my attitude towards WAF is that there is no need to deify WAF. It is not as magical as the manufacturer said, but it is also not to look down on WAF too much. After all, WAF can block most of the conventional attacks, greatly improve the security of web applications, and is an effective means of web application protection.