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漏洞。
<?phpif(basename($_SERVER['SCRIPT_NAME']) ==basename($_SERVER['SCRIPT_FILENAME']))echo dirname($_SERVER['SCRIPT_NAME']);?>GET /index.php/<script>alert(1)</script>/index.phpSCRIPT_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 ErrorServer: nginx/1.10.3Content-Type: text/htmlContent-Length: 34Connection: close
但是，如果发送无效的HTTP要求，例如：
GET /? XTTP/1.1Host: 127.0.0.1Connection: close
Nginx的相应则为：
XTTP/1.1 500 ErrorContent-Type: text/htmlSecret-Header: secret-infoSecret info, should not be visible!merge_slashes设置为off
merge_slashes指令是一种Nginx默认的机制，用来肃清两个或更多的斜杠，默认设置为“开”，这样///被转码为/。如果将Nginx用作反向代理，并且正在代理的运用程序随意马虎受到本地文件包含的影响，则在要求中利用额外的斜杠可能会留出利用空间。为防止被恶意利用，可以设置merge_slashes设置为“off”。
结论Nginx是一个非常强大的Web做事器平台，大家都喜好利用Nginx，但是不一定都做了合理的配置,如果配置不当，则可能会对系统安全产生影响，配置时候不要直接通过复制粘贴就直接上线用，建议通过官方网站或者一些安全建议的配置，比如mozilla的Nginx安全配置建媾和在线安全配置天生器。
