前言：
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后面，也可能發生在rewrite、add_header、p roxy_set_header、proxy_pass之后。
修復方式：將$uri或者$document_uri改為 $request_uri。
0×02 SSRF
SSRF(服務端請求偽造)漏洞常出現在反向代理的配置中，反向代理的語法如下：proxy_pass http ://IP
如果攻擊者可以操控IP, 將其修改成內網IP地址即可造成SSRF漏洞。
0×03目錄遍歷
autoindex off;#是否開啟目錄列表訪問，默認關閉。
若設置成autoindex on;

Nginx不安全配置可能導致的安全漏洞Nginx不安全配置可能導致的安全漏洞
Nginx不安全配置可能導致的安全漏洞
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;

Nginx配置安全檢查的工具
Github上開源了一款Nginx配置安全檢查的工具，叫做gixy，可以覆蓋以上的部分問題。
項目地址： https://github.com/yandex/gixy
工具是用python編寫的，python2.7和3.5+版本都支持。可以直接用pip來安裝：pip install gixy。
使用起來也很簡單，直接將 gixy 命令后面加上 ningx.conf 文件的具體位置即可。