服务器500错误原因(Nginx安全之错误配置及实例分析)

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 TemporarilyServer: nginx/1.13.0Content-Type: text/htmlContent-Length: 161Connection: closeLocation: xxxxxSet-Cookie:helloSCRIPT_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设置为offmerge_slashes指令是一种Nginx默认的机制,用来消除两个或更多的斜杠,默认设置为“开”,这样///被转码为/。如果将Nginx用作反向代理,并且正在代理的应用程序容易受到本地文件包含的影响,则在请求中使用额外的斜杠可能会留出利用空间。为防止被恶意利用,可以设置merge_slashes设置为“off”。 结论Nginx是一个非常强大的Web服务器平台,大家都喜欢使用Nginx,但是不一定都做了合理的配置,如果配置不当,则可能会对系统安全产生影响,配置时候不要直接通过复制粘贴就直接上线用,建议通过官方网站或者一些安全建议的配置,比如mozilla的Nginx安全配置建议和在线安全配置生成器。

本文出自快速备案,转载时请注明出处及相应链接。

本文永久链接: https://www.175ku.com/26894.html