Nginx不安全配置可能導致的安全漏洞

KanEff 7年前發布 | 32K 次閱讀 Nginx 安全漏洞 Web服務器

前言：

Nginx (engine x) 是一個高性能的http和反向服務器，也可以作為IMAP/POP3/SMTP服務器。t engine是由淘寶網發起的Web服務器項目。它在 Nginx 的基礎上，針對大訪問量網站的需求，添加了很多高級功能和特性。

在滲透測試過程中發現很多網站使用了nginx或者tenginx來做反向代理，ningx的配置文件nginx.conf的一些錯誤配置可能引發一些安全漏洞。下面是總結的一些可能引發安全問題的錯誤配置，并且推薦了github上一款用于檢測nginx安全配置的工具。

Ningx.conf配置一共分為4部分： 1.頂級配置 2. Events 模塊 3.http部分 4.server部分

0×00任意文件讀取

這個常見于Nginx做反向代理的情況，動態的部分被proxy_pass傳遞給后端端口，而靜態文件需要Nginx來處理。假設靜態文件存儲在/home/目錄下，而該目錄在url中名字為files，那么就需要用alias設置目錄的別名：

location /files {

alias /home/;

}

此時訪問 http://127.0.0.1:8080/files/1.txt ，就可以獲取 /home/1.txt 文件。

我們發現，url上 /files 沒有加后綴 / ，而alias設置的 /home/ 是有后綴 / 的，這個 / 就導致我們可以從 /home/ 目錄穿越到他的上層目錄，造成任意文件下載：

修復方法：不寫成上面那種有漏洞的形式，比如可以寫成結尾都帶著 / 字符。

0×01$uri導致的CRLF注入

在實際業務場景中經常需要在nginx中配置路徑跳轉。

比如用戶訪問http://x.com 自動跳轉到https://x.com 或者是訪問 http://x.com 自動跳轉到 http://www.x.com

在跳轉的過程中，我們需要保證用戶訪問的頁面不變，所以需要從Nginx獲取用戶請求的文件路徑，有三個可以表示uri的變量：

$uri

$document_uri

$request_uri

$uri 和 $document_uri表示的是解碼以后的請求路徑，不帶參數,$request_uri表示的是完整的URI（沒有解碼）,如果在nginx.conf中配置了下列的代碼：

location /test {
             return 302 http://$host:81$uri;
                 }

因為 $uri 是解碼以后的請求路徑，所以可能就會包含換行符，也就造成了一個CRLF注入漏洞。

該漏洞除了發生在 return后面，也可能發生在r ewrite、 a dd_header、p roxy_set_header、p roxy_pass之后。

修復方式：將 $uri或者$document_uri 改為 $request_uri 。

0×02 SSRF

SSRF(服務端請求偽造)漏洞常出現在反向代理的配置中，反向代理的語法如下：proxy_pass http ://IP

如果攻擊者可以操控IP, 將其修改成內網IP地址即可造成SSRF漏洞。

0×03目錄遍歷

autoindex off; #是否開啟目錄列表訪問，默認關閉。

若設置成 autoindex on;

0x04nginx版本泄露

對于nginx服務器，之前曾爆出過不同版本的解析漏洞，比如 nginx 0.7.65以下（0.5.*, 0.6.*, 0.7.* ）全版本系列和0.8.37（0.8.*）以下8系列受影響。下面假設在存在漏洞的站點上有一張圖片url地址為： http://x.x.x.x/logo.jpg 而當我們正常訪問圖片時，nginx會把這個當作非腳本語言直接讀取傳送會客戶端（也就是瀏覽器），但是

存在解析漏洞的nginx會把如下連接解析并且當作php文件執行~：

http://x.x.x.x/logo.jpg/x.php

http://x.x.x.x/logo.jpg%00x.php

因此隱藏 Nginx 的版本號，提高安全性。

在配置文件nginx.conf里面,設置如下： server_tokens off;