Nginx是支持世界上所有网站三分之一的Web服务器。因为轻巧，模块化，用户友好的配置格式以强大的反向代理能力，Nginx迅速取代其他Web服务器成了互联网上最常用Web服务器之。作为一个门户和对外暴露的入口，Nginx也是Web服务在保障企业服务在性能和安全方面功不可没，虽然Nginx也暴露过一些漏洞（比如CVE-2013-4547,CVE-2017-7529，CVE-2018-16843/16844,CVE-2019-9516和CVE-2020-12440等），但是基本上都无法直接（难于）利用。但是没有漏洞，不等于不能被利用（同样有漏洞，不等于可以利用）。Nginx最大的安全问题并不是其安全漏洞，而是在运维上面，尤其是错误配置导致的问题。本文我们就介绍Nginx常见的配置错误，及其导致的安全问题（风险）。
Web目录配置不当
典型示例：
server {
root /etc/nginx;
location /Chongcong.html {
try_files $uri$uri/=404;
proxy_pass http://127.0.0.1:8080/;
}
}解析：
上述配置中由于图省事，直接把Nginx的Web根文件指定成了/etc/nginx。一般情况下/etc/nginx是nginx的配置目录，所有Nginx配置文件都位于该目录，而上述配置下所有该目录都就可以被访问。由于配置location个根目录/请求规则 (location / {...})，仅用于/ Chongcong.html。因此，root指令将被location继承，所有的/请求，都会访问/etc/nginx。
比如请求/nginx.conf就会直接能访问实例Nginx配置信息。更有甚者如果root设置为/etc，则GET请求/pawsswd，/shadow就能访问系统的用户信息和用户密码哈希（如果权限设置）。
根据安全网站统计，有关Nginx配置中常见的误用路径有：
目录分隔符（/）配置不当
典型示例：
server {
listen 80 default_server;
server_name _;
location /static {
alias /usr/share/nginx/static/;
}
location /api {
proxy_pass http://apiserver/v1/;
}
}解析：
上述配置中，由于缺少斜杠，因此导致了目录穿越，通过location伪指令中缺少尾随斜杠与伪指令相结合alias，可以访问到上一层的目录，读取Web应用程序的源代码等私密信息。还可以让proxy_pass和其他指令结合使用。
location /api {
proxy_pass http://apiserver/v1/;
}上述配置由于配置对进apiserver的接口访问，假定只允许访问/apiserver/v1/的接口，即
/server/api/user === /apiserver/v1//user当请求server/api/user时，Nginx将首先会规范化转码URL。然后，它会检查前缀是否/api与URL匹配，在该情况下，URL会匹配。然后从URL中删除前缀，并保留/user路径。然后该路径添加到proxy_pass URL中，从而生成最终URL /apiserver/v1//user。
注意，该URL中存在双斜杠，由于location指令不以斜杠结尾，而且proxy_pass URL路径要以斜杠结尾。大多数Web服务器会自动纠错/apiserver/v1//user为/apiserver/v1/user，即使配置错误，所有内容仍可以正常运行，并且并不会报错，所以很难被发现。
但是，该错误配置，可以通过精心设置的Url请求设置加以利用，比如：/server/api../，将会导致Nginx请求/apiserver/v1/../，会被标准化为的URL /apiserver/。例如，可能导致访问服务器状态信息/server/api../server-status，或者可能使不希望公开访问的路径可访问。
Nginx服务器配置错误的检查方法，当URL中的斜杠被删除时，服务器仍会返回相同的响应。例如，/server/api/user和/server/apiuser返回相同的内容，服务器可能是脆弱的。这将导致发送以下请求转化：
/server/api/user === /apiserver/v1//user
/server/apiuser === /apiserver/v1/user配置变量误用
一些框架，脚本需要在Nginx配置做专门的配置，需要使用Nginx内置的配置变量。如果这些变量配置误用，则可能会导致诸如XSS， HttpOnly保护绕过，信息泄露甚至在远程执行等严重的安全漏洞。
$URL误用和 CRLF注入
Nginx配置中常见的一个变量误用了$uri或$document_uri而没有使用更安全的$request_uri。$uri和$document_url是转码化规范化的URI，$request_uri而会对请求的URL进行安全正规化转码处理，会将一些特殊字符转码以免被恶意利用。如果在配置中直接使用$uri和$document_url则可能导致会被利用引起CLRF跨站请求攻击。
典型示例：
location / {
return 302 https://$hosts$uri;
}解析：
HTTP请求的新行字符为\r（回车）和\n（换行）。对新行字符进行URL编码会导致以下字符表示%0d%0a。当这些字符包含在请求中（例如localhost/%0a%0dSet-Cookie：hello）时，由于$uri变量包含URL解码的换行字符，服务器响应，修改后的HTTP头。
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.13.0
Content-Type: text/html
Content-Length: 161
Connection: close
Location: xxxxx
Set-Cookie：hello
SCRIPT_NAME误用
另一个典型错误是Nginx做反向代理时，反向代理到后端应用服务器，对SCRIPT_NAME变量的误用。
典型示例：
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
}解析：
主要的问题是，即使服务器上不存.php该文件，Nginx也会将所有URL发送到PHP解释器。 如果PHP应用，用了SCRIPT_NAME于构建基本URL，则会导致将XSS漏洞。
<?php
if(basename($_SERVER['SCRIPT_NAME']) ==
basename($_SERVER['SCRIPT_FILENAME']))
echo dirname($_SERVER['SCRIPT_NAME']);
?>
GET /index.php/<script>alert(1)</script>/index.php
SCRIPT_NAME = /index.php/<script>alert(1)</script>/index.php后端响应转发
使用Nginx proxy_pass，可以拦截后端创建的错误和HTTP标头。如果要隐藏内部错误消息和标头，而交由Nginx处理，用着非常方便。对后端的应答，Nginx将自动提供一个自定义错误页面。但是有可能遇到Nginx无法理解的HTTP响应。如果客户端向Nginx发送无效的HTTP请求(状态吗)，则该请求将按原样转发到后端，后端将使用其原始内容进行应答。然后，Nginx也无法理解无效的HTTP的响应，而只是原始的将其转发给客户端。想象一下这样的uWSGI应用程序：
def application(environ, start_response):
start_response('500 Error', [('Content-Type',
'text/html'),('Secret-Header','secret-info')])
return [b"Secret info, should not be visible!"]如果Nginx中配置如下：
http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}如果后端的响应状态大于300，proxy_intercept_errors将提供自定义响应。在上面的uWSGI应用程序中，发送一个500 Error Nginx会拦截的响应。
proxy_hide_header可以将从客户端隐藏任何指定的HTTP标头。 如果我们发送正常GET请求，Nginx将返回：
HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: close但是，如果发送无效的HTTP请求，例如：
GET /? XTTP/1.1
Host: 127.0.0.1
Connection: closeNginx的响应则为：
XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info
Secret info, should not be visible!merge_slashes设置为off
merge_slashes指令是一种Nginx默认的机制，用来消除两个或更多的斜杠，默认设置为“开”，这样///被转码为/。如果将Nginx用作反向代理，并且正在代理的应用程序容易受到本地文件包含的影响，则在请求中使用额外的斜杠可能会留出利用空间。为防止被恶意利用，可以设置merge_slashes设置为“off”。
结论
Nginx是一个非常强大的Web服务器平台，大家都喜欢使用Nginx，但是不一定都做了合理的配置,如果配置不当，则可能会对系统安全产生影响，配置时候不要直接通过复制粘贴就直接上线用，建议通过官方网站或者一些安全建议的配置，比如mozilla的Nginx安全配置建议和在线安全配置生成器。