Nginx location 语法匹配详解，渗透漏洞WEB-INF文件泄露修复

亦凉 2023-10-06 20:54 2阅读 0赞

### **1、语法规则，类似switch case** ###

location \[=|~|~\*|^~|!~|!~\*\] /uri/ \{ … \}

<table> 
 <thead> 
 <tr> 
 <td style="background-color:#eff3f5;border-color:#dddddd;"> 模式 </td> 
 <td style="background-color:#eff3f5;border-color:#dddddd;"> 含义 </td> 
 </tr> 
 </thead> 
 <tbody> 
 <tr> 
 <td style="background-color:#ffffff;border-color:#dddddd;"> location = /uri </td> 
 <td style="background-color:#ffffff;"> = 表示精确匹配 </td> 
 </tr> 
 <tr> 
 <td style="background-color:#f7f7f7;border-color:#dddddd;"> location ^~ /uri </td> 
 <td style="background-color:#f7f7f7;"> ^ 进行前缀匹配，~ 表示区分大小写 </td> 
 </tr> 
 <tr> 
 <td style="background-color:#ffffff;border-color:#dddddd;"> location ~ pattern </td> 
 <td style="background-color:#ffffff;"> ~ 区分大小写的匹配 </td> 
 </tr> 
 <tr> 
 <td style="background-color:#f7f7f7;border-color:#dddddd;"> location ~* pattern </td> 
 <td style="background-color:#f7f7f7;"> ~* 不区分大小写的匹配 </td> 
 </tr> 
 <tr> 
 <td style="background-color:#ffffff;border-color:#dddddd;"> location /uri </td> 
 <td style="background-color:#ffffff;"> 不带任何修饰符，也表示前缀匹配，但是在正则匹配之后 </td> 
 </tr> 
 <tr> 
 <td style="background-color:#f7f7f7;border-color:#dddddd;"> location / </td> 
 <td style="background-color:#f7f7f7;"> 通用匹配，任何未匹配到其它 location 的请求都会匹配到，相当于 switch 中的 default </td> 
 </tr> 
 <tr> 
 <td style="background-color:#ffffff;border-color:#dddddd;"> location !~ </td> 
 <td style="background-color:#ffffff;"> 区分大小写不匹配 </td> 
 </tr> 
 <tr> 
 <td style="background-color:#f7f7f7;border-color:#dddddd;"> location !~* </td> 
 <td style="background-color:#f7f7f7;"> 不区分大小写不匹配 </td> 
 </tr> 
 </tbody> 
</table>

**匹配优先级**

*  首先精确匹配 =
 *  其次前缀匹配 ^~
 *  其次是按文件中顺序的正则匹配
 *  然后匹配不带任何修饰的前缀匹配
 *  最后是交给 / 通用匹配
 *  当有匹配成功时候，停止匹配，按当前匹配规则处理请求

匹配的时候依照最佳匹配规则，按照能匹配到的最多的规则进行匹配  
如 location ^~ /test/react/ 和 location ^~ /test/，请求 http://localhost/test/react/react.dev.js，会匹配 location /test/react/

###  ###

### 2、语法示例 ###

有如下匹配规则：

location = / {
        echo "规则A";
    }
    location = /login {
        echo "规则B";
    }
    location ^~ /static/ {
        echo "规则C";
    }
    location ^~ /static/files {
        echo "规则X";
    }
    location ~ \.(gif|jpg|png|js|css)$ {
        echo "规则D";
    }
    location ~* \.png$ {
        echo "规则E";
    }
    location /img {
        echo "规则Y";
    }
    location / {
        echo "规则F";
    }

则产生的效果如下：

*  访问根目录`/`，比如`http://localhost/`将匹配规则 A
 *  访问`http://localhost/login`将匹配规则 B，`http://localhost/register`则匹配规则 F
 *  访问`http://localhost/static/a.html`将匹配规则 C
 *  访问`http://localhost/static/files/a.exe`将匹配规则 X，虽然规则 C 也能匹配到，但因为最大匹配原则，最终选中了规则 X。
 *  访问`http://localhost/a.gif`，`http://localhost/b.jpg`将匹配规则 D 和规则 E，但是规则 D 顺序优先，规则 E 不起作用，而`http://localhost/static/c.png`则优先匹配到规则 C。
 *  访问`http://localhost/a.PNG`则匹配规则 E，而不会匹配规则 D，因为规则 E 不区分大小写。
 *  访问`http://localhost/img/a.gif`会匹配上规则 D，虽然规则 Y 也可以匹配上，但是因为正则匹配优先，而忽略了规则 Y。
 *  访问`http://localhost/img/a.tiff`会匹配上规则 Y。
 *  访问`http://localhost/category/id/111`则最终会匹配到规则 F，因为以上规则都不匹配，这个时候应该是 Nginx 转发请求给后端应用服务器，比如 FastCGI(php)，tomcat(jsp)，Nginx 作为反向代理服务器存在。

### **3、应用示例，**渗透漏洞WEB-INF文件泄露修复 ###

测试发现javax.faces.resource.../WEB-INF/目录工程文件泄露。

Web.xml:

http://192.168.1.2:8081/项目名/javax.faces.resource.../WEB-INF/web.xml.jsf

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP55m-6I-c_size_20_color_FFFFFF_t_70_g_se_x_16][]

Application.xml:

http://192.168.1.2:8081/项目名/javax.faces.resource.../WEB-INF/classes/applicationContext.xml.jsf

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP55m-6I-c_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

需要拦截WEB-INF文件，配置如下

location ~ /(WEB-INF|META-INF)/* {  
                        #deny all;
                        return 404;  
                    }

表示 url地址包含WEB-INF或者META-INF 走第一个location

否则其他所有地址走第二个location

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP55m-6I-c_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

转载：

[Nginx location 匹配详解、location \[=|~|~\*|^~|!~|!~\*\] 详解\_止水聊技术-CSDN博客][Nginx location _location _ _-CSDN]

[Nginx之 Location 的生成 - 季末的天堂 - 博客园][Nginx_ Location _ - _ -]

[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP55m-6I-c_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/3d1b9837b3f34739aa6c43eaffc85ae3.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5bCP55m-6I-c,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP55m-6I-c_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/367370c30814415098fff11f59972ce4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5bCP55m-6I-c,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5bCP55m-6I-c_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/d23b646ceb394e09a663ee2e1eb7e7f4.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5bCP55m-6I-c,size_20,color_FFFFFF,t_70,g_se,x_16
[Nginx location _location _ _-CSDN]: https://blog.csdn.net/qq_32281471/article/details/94628445
[Nginx_ Location _ - _ -]: https://www.cnblogs.com/jimodetiantang/p/9246407.html