Nginx配置指令location匹配符优先级和安全问题

使用nginx 很久了,它的性能高,稳定性表现也很好,得到了很多人的认可。特别是它的配置,有点像写程序一样,每行命令结尾一个";"号,语句块用"{}"括起来。 配制好,直接nginx -t 检查配制情况,配制成功,直接运行:service nginx reload .服务器没有任何宕机情况下,实现平稳修改配置

最近一直在做location 配置,遇到优先级别问题(如果配置不当可能存在安全隐患哦),以下是个人学习一点体会。

一、 location 的匹配符
1.等于匹配符:=
等于匹配符就是等号,特点可以概括为两点:
精确匹配
不支持正则表达式
2.空匹配符
空匹配符的特点是:
匹配以指定模式开始的 URI
不支持正则表达式
3.正则匹配符:~
正则匹配符是可以使用正则表达式的匹配符。不过这里要强调的是,一般来说~是指:
区分大小写的正则匹配
而~*表示:
不区分大小写的正则匹配
但是对于一些对大小写不敏感的操作系统,这两者没有区别。另外一个就是^~,其表示以指定模式开始的正则匹配。

4.内部访问符:@
一般用于错误页面等,这个暂不讨论。

二、匹配符优先级
1.=
2.空匹配符,满足精确匹配时
3.^~
4.~或~*
5.空匹配符,满足以指定模式开始时的匹配时
这样说比较抽象,我们来看例子吧。

2.1 等于匹配符与精确匹配时的空匹配符

看下面的例子(用到我们此前一起完成的Hello World模块):

复制代码 代码如下:

location /poechant {
    hello_world no1;
}

 

location = /poechant {
    hello_world no2;
}

如果我们的请求是http://my.domian/poechant,则我们发现两个location都与请求的 URI 匹配,这时根据我们的优先级顺序,第一个是精确匹配时的空匹配符,第二个是等于匹配符,所以第二个的优先级高,也就是应该输出:

 

hello_world, no2
同时也说明 Nginx 的 locatoin 不是按照配置文件中的书写顺序来匹配的。

2.2 精确匹配时的空匹配符与正则匹配的^~

下面这个例子中,两者开始都精确匹配了,连这个正则匹配都是精确匹配。

复制代码 代码如下:

location ^~ ^/poechant$ {
    hello_world no1;
}

 

location /poechant {
    hello_world no2;
}

匹配哪一个?你测试一下,会得到:

 

hello_world, no2
与我们上面说的优先级顺序相吻合。
2.3 其他匹配优先级比较的实例

三、实战经验总结

1.location 匹配的优先级(来自实践总结中)
(location =) > (location 完整路径 >) >(location ^~ 路径) >(location ~* 正则) >(location 路径)
只要匹配到,其它的都会忽略,然后返回到改匹配。
用以下例子来测试:

 

复制代码 代码如下:

#1   
location / {
   return 500;
}
#2
location /a/ {
    return 404;
}
#3
location ~* \.jpg$ {
    return 403;
}
#4
location ^~ /a/ {
    return 402;
}
#5
location  /a/1.jpg {
    return 401;
}
#6
location = /a/1.jpg {
    return 400;
}

 

说明:测试的时候,先要将#2全部注释掉,不然会认为#2 与#4 完全一样。会提示:重复配置,提示如下

复制代码 代码如下:

D:\nginx-0.8.7>nginx -s reload
[emerg]: duplicate location "/a/" in D:\nginx-0.8.7/conf/nginx.conf:53

 

浏览测试:每次都是访问:http://localhost:9999/a/1.jpg (在windows 安装测试,然后端口是9999) 文件a/1.jpg 根本不存在。关键是测试看页面返回情况。

a.用上面的配置请求后的结果

 

复制代码 代码如下:

400 Bad Request
--------------------------------------------------------------------------------
nginx/0.8.7

从测试中可以看到,优先级最高的是:= 号。 它会最先匹配到。
b.接下来我们 屏蔽掉 #6 如下:

复制代码 代码如下:

#6
#    location = /a/1.jpg {
#        return 400;
#    }

 

然后重载配置:D:\nginx-0.8.7> nginx -s reload  并访问:http://localhost:9999/a/1.jpg ,返回以下结果:

复制代码 代码如下:

401 Authorization Required
--------------------------------------------------------------------------------
nginx/0.8.7

 

结论:从这个测试发现,没有“=”情况下,location 后面直接接完整路径是优先匹配。 通过测试发现,如果将:location/a/1.jpg   改成:location /a/1\.jpg
会出现意外情况,直接出现是:return 402.  从这一点,可以推测到nginx 匹配优先是:网站路径,并且不带正则表达式的优先。

c.同理测试 屏蔽掉 #5 如下:注释及重新加载同上.
访问:http://localhost:9999/a/1.jpg 返回如下结果。

复制代码 代码如下:

402 Payment Required
--------------------------------------------------------------------------------
nginx/0.8.7

 

结论:通过这个测试可以得出:location ^~ 优先级 高于 location ~* 优先级 ,其中:^~ 主要后面接路径。

c.同理测试 屏蔽掉 #4 如下:注释及重新加载同上.
访问:http://localhost:9999/a/1.jpg 返回如下结果。

复制代码 代码如下:

403 Forbidden
--------------------------------------------------------------------------------
nginx/0.8.7

结论:从以上比较得到,正则优先 未带任何匹配符的路径匹配

 

d.同理测试 屏蔽掉 #3 如下:注释及重新加载同上. 并且去掉#2 的注释“#”
访问:http://localhost:9999/a/1.jpg 返回如下结果。

复制代码 代码如下:

404 Not Found
--------------------------------------------------------------------------------
nginx/0.8.7

结论:比较有意思是:/a/ 与 /  应该是 同种类型的匹配表达式, 可以从中得到,该匹配顺序是,将路径从右匹配, 可以推测形如逐个字符,那个先匹配到,就是那个优先。 因此得到是:/a/ 优先于 / .

 

以上测试,是我测试结果,优先级别以以上规律。 在实际我们书写中,经常会犯错误。 还记得前段时间:80后安全团队曝nginx漏洞 其实,个人认为不能算是nginx 漏洞,只是,我们不了解nginx 配制规则,而出现一个配置上面致命漏洞而已。 其实,通过上面优先级,我们在配置时候可能也一样经常犯一个致命错误。

复制代码 代码如下:

#以下是随便写例子,个人可能各不相同
#假设站点在:/home/www/html/目录下,所有的php 及上传文件都在这个目录下面。
location ~* \.php$ {
    proxy_pass http://www.a.com;
}

 

location  /upload/ {
    alias   /home/www/html/upload/;
}

 

而且,这个upload 目录,是静态目录,我们想法是下面所有文件是不能够执行的,包括php文件。
如果有用户访问:http://www.a.com/upload/1.css , 会直接显示该css, 但是,如果有用户访问:http://www.a.com/upload/1.php  类似文件,正如上面所说,实际匹配到:~* \.php$  了。 upload 下面是执行了。
从这个里面,我们发现一个问题,实际没有达到我们要求。 静态目录下面的文件一样执行了。 这下比较麻烦了。 一旦出现个什么上存漏洞的,别人上存了一个php,我们还以为,我们配置是ok的。 觉得很安全,缺在不知不觉中被别人打开一扇门。

那么我们怎么样修改呢?

 

复制代码 代码如下:

location ~* \.php$ {
    proxy_pass http://www.a.com;
}
location ^~ /upload/ {
    alias   /home/www/html/upload/;
}

 

对,就是必须用:"^~" ,这样是不是就已经安全了呢。 如果你再访问下:http://www.a.com/upload/1.php  你会发现,这段代码源码显示出来了。 这个其实对于我们而言也是不想见到了。 一段显示源码,在各个搜索引擎,很容易通过所有特殊关键字,搜索到改文件的。
那么我们该怎么样配置安全的上存目录呢? 对,你想到了:限制允许的特殊文件类型。

复制代码 代码如下:

location ~* \.php$ {
    proxy_pass http://www.a.com;
}

 

location ^~ /upload/ {
  if ($request_filename ! ~* \.(jpg|jpeg|gif|png|swf|zip|rar|txt)$) {
  return 403;
    }
    alias   /home/www/html/upload/;
}

 

只要不是满足上面扩展名文件,就自动提示:403 不能访问,有可以避免源代码显示。
刚才从匹配结果已经知道了,同级不带任何匹配符的,是以右为准匹配。 那么,如果都用正则表达式,以什么方式匹配呢?
测试如下:(新建配置文件,server 包含)

复制代码 代码如下:

    location ~* \.jpg$ {
            return 402;
    }

 

    location ~* 1\.jpg$ {
            return 403;
    }

 

结果如下:

 

复制代码 代码如下:

402 Payment Required
--------------------------------------------------------------------------------
nginx/0.8.7

 

看来是返回的是:402 上面一个呢。 按理论说,1.jpg 配置 比 .jpg 更准确,看来跟上面说的顺序不同,那它会不会是那个在前以那个匹配呢? 我们再测试下:

复制代码 代码如下:

location ~* 1\.jpg$ {
            return 403;
    }

 

    location ~* \.jpg$ {
            return 402;
    }

 

返回结果是:

 

复制代码 代码如下:

403 Forbidden
--------------------------------------------------------------------------------
nginx/0.8.7

 

哈哈,恰好相反,看来我的推断是正确的,如果都是正则,都能够匹配,以配置文件出现顺序来,谁在前谁优先。 一口气说了,不知道朋友你,明白我的思路吗?这样的比较会很多很多,大家可以逐一测试。 熟悉location 配置,对于熟练运用nginx 是一个必备基础。 因为nginx 太灵活,也太流行了。上面的问题,也许朋友你,会遇到。希望对你有帮助。

时间: 2024-09-12 00:58:37

Nginx配置指令location匹配符优先级和安全问题的相关文章

Nginx学习之location匹配规则

介绍 location指令是http模块当中最核心的一项配置,根据预先定义的URL匹配规则来接收用户发送的请求,根据匹配结果,将请求转发到后台服务器.非法的请求直接拒绝并返回403.404.500错误处理等. location 的匹配符 ~ 波浪线表示执行一个正则匹配,区分大小写 ~* 表示执行一个正则匹配,不区分大小写 ^~ 表示普通字符匹配,如果该选项匹配,只匹配该选项,不匹配别的选项,一般用来匹配目录 = 进行普通字符精确匹配 @ 定义一个命名的 location,使用在内部定向时,例如

简介Nginx中的location匹配规则_nginx

location匹配命令 ~      #波浪线表示执行一个正则匹配,区分大小写 ~*    #表示执行一个正则匹配,不区分大小写 ^~    #^~表示普通字符匹配,如果该选项匹配,只匹配该选项,不匹配别的选项,一般用来匹配目录 =      #进行普通字符精确匹配 @     #"@" 定义一个命名的 location,使用在内部定向时,例如 error_page, try_files location 匹配的优先级(与location在配置文件中的顺序无关) = 精确匹配会第一个

Nginx 配置指令的执行顺序(六)

前面我们在 (五) 中提到,在一个 location 中使用 content 阶段指令时,通常情况下就是对应的 Nginx 模块注册该 location 中的"内容处理程序".那么当一个 location 中未使用任何 content 阶段的指令,即没有模块注册"内容处理程序"时,content 阶段会发生什么事情呢?谁又来担负起生成内容和输出响应的重担呢?答案就是那些把当前请求的 URI 映射到文件系统的静态资源服务模块.当存在"内容处理程序"

Nginx 配置指令的执行顺序(七)

来看一个 ngx_static 模块服务磁盘文件的例子.我们使用下面这个配置片段:     location / {        root /var/www/;    } 同时在本机的 /var/www/ 目录下创建两个文件,一个文件叫做 index.html,内容是一行文本 this is my home:另一个文件叫做 hello.html,内容是一行文本 hello world. 同时注意这两个文件的权限设置,确保它们都对运行 Nginx worker 进程的系统帐户可读.       

Nginx 配置指令的执行顺序(十一)

紧跟在 post-access 阶段之后的是 try-files 阶段.这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序.由于 try_files 指令在许多 FastCGI 应用的配置中都有用到,所以我们不妨在这里简单介绍一下.       try_files 指令接受两个以上任意数量的参数,每个参数都指定了一个 URI. 这里假设配置了 N 个参数,则 Nginx 会在 try-files 阶段,依次把前 N-1 个参数映射为文件系统上的对

Nginx 配置指令的执行顺序(九)

紧接在 server-rewrite 阶段后边的是 find-config 阶段.这个阶段并不支持 Nginx 模块注册处理程序,而是由 Nginx 核心来完成当前请求与 location 配置块之间的配对工作.换句话说,在此阶段之前,请求并没有与任何 location 配置块相关联.因此,对于运行在 find-config 阶段之前的 post-read 和 server-rewrite 阶段来说,只有 server 配置块以及更外层作用域中的配置指令才会起作用.这就是为什么只有写在serve

Nginx 配置指令的执行顺序(三)

如前文所述,除非像 ngx_set_misc 模块那样使用特殊技术,其他模块的配置指令即使是在 rewrite 阶段运行,也不能和 ngx_rewrite 模块的指令混合使用.不妨来看几个这样的例子.       第三方模块 ngx_headers_more 提供了一系列配置指令,用于操纵当前请求的请求头和响应头.其中有一条名叫 more_set_input_headers 的指令可以在 rewrite 阶段改写指定的请求头(或者在请求头不存在时自动创建).这条指令总是运行在 rewrite 阶

Nginx 配置指令的执行顺序(十)

运行在 post-rewrite 阶段之后的是所谓的 preaccess 阶段.该阶段在 access 阶段之前执行,故名preaccess.       标准模块 ngx_limit_req 和 ngx_limit_zone 就运行在此阶段,前者可以控制请求的访问频度,而后者可以限制访问的并发度.这里我们仅仅和它们打个照面,后面还会有机会专门接触到这两个模块.       前面反复提到的标准模块 ngx_realip 其实也在这个阶段注册了处理程序.有些读者可能会问:"这是为什么呢?它不是已经

Nginx 配置指令的执行顺序(四)

 ngx_lua 模块提供了配置指令 access_by_lua,用于在 access 请求处理阶段插入用户 Lua 代码.这条指令运行于 access 阶段的末尾,因此总是在 allow 和 deny 这样的指令之后运行,虽然它们同属 access 阶段.一般我们通过 access_by_lua 在 ngx_access 这样的模块检查过客户端 IP 地址之后,再通过 Lua 代码执行一系列更为复杂的请求验证操作,比如实时查询数据库或者其他后端服务,以验证当前用户的身份或权限.       我