之前在Sec-News中推薦了一個開源程序??https://github.com/yandex/gixy，作用是來檢測Nginx配置文件中存在的問題。正好Pwnhub上周的比賽也出現了一道題，包含由Nginx配置錯誤導致的漏洞。

所以我挑選我覺得比較

趣，而且很有可能犯錯誤的三個典型案例，來說說Nginx配置文件的安全。

另外，本文所涉及的三個案例，均已上線到Vulhub（?https://github.com/phith0n/vulhub/tree/master/nginx/insecure-configuration?），閱讀本文的同時可以自己動手測試。

$uri導致的CRLF注入漏洞

下面兩種情景十分常見：

用戶訪問http://example.com/aabbcc，自動跳轉到https://example.com/aabbcc

用戶訪問http://example.com/aabbcc，自動跳轉到http://www.example.com/aabbcc

比如我的博客，訪問http://www.leavesongs.com/other/tinger.html，將會301跳轉到https://www.leavesongs.com/other/tinger.html。隨著現在https的普及，很多站點都強制使用https訪問，這樣的跳轉非常常見。

第二個場景主要是為了統一用戶訪問的域名，更加有益于SEO優化。

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

1.$uri

2.$document_uri

3.$request_uri

解釋一下，1和2表示的是解碼以后的請求路徑，不帶參數;3表示的是完整的URI(沒有解碼)。那么，如果運維配置了下列的代碼:

location / {

? ? return 302 https://$host$uri;

}

因為$uri是解碼以后的請求路徑，所以可能就會包含換行符，也就造成了一個CRLF注入漏洞。（關于CRLF注入漏洞，可以參考我的老文章?https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html?）

這個CRLF注入漏洞可以導致會話固定漏洞、設置Cookie引發的CSRF漏洞或者XSS漏洞。其中，我們通過注入兩個\r\n即可控制HTTP體進行XSS，但因為瀏覽器認為這是一個300跳轉，所以并不會顯示我們注入的內容。

這個情況下，我們可以利用一些技巧：比如使用CSP頭來iframe的地址，這樣瀏覽器就不會跳轉，進而執行我們插入的HTML：

關于上述利用方法，可以參考我的另一篇文章

《Bottle HTTP 頭注入漏洞探究》。

如何修復這個CRLF漏洞？正確的做法應該是如下：

location / {

? ? return 302 https://$host#request_uri;

}

另外，由$uri導致的CRLF注入漏洞不僅可能出現在上述兩個場景中，理論上，只要是可以設置HTTP頭的場景都會出現這個問題。

目錄穿越漏洞

這個常見于Nginx做反向代理的情況，動態的部分被proxy_pass傳遞給后端端口，而靜態文件需要Nginx來處理。

假設靜態文件存儲在/home/目錄下，而該目錄在url中名字為files，那么就需要用alias設置目錄的別名:

location /files {

? ?alias /home/;

}

此時，訪問http://example.com/files/readme.txt,就可以獲取/home/readme.txt文件。

但我們注意到，url上/files沒有加后綴/,而alias設置的/home/是有后綴/的，這個/就導致我們可以從/home/目錄穿越到他的上層目錄:

進而我們獲得了一個任意文件下載漏洞。

這個有趣的漏洞出現在了Pwnhub上一期比賽《尋找 SNH48》中，@Ricter師傅的題目。

如何解決這個漏洞？只需要保證location和alias的值都有后綴/或都沒有這個后綴。

Http Header被覆蓋的問題

眾所周知，Nginx的配置文件分為Server、Location、If等一些配置塊，并且存在包含關系，和編程語言比較類似。如果在外層配置的一些選項，是可以被繼承到內層的。

但這里的繼承也有一些特性，比如add_header，子塊中配置后將會覆蓋父塊中的add_header添加的所有HTTP頭，造成一些安全隱患。

如下列代碼，Server塊添加了CSP頭：

server {...add_header Content-Security-Policy "default-src 'self'";add_header X-Frame-Options DENY;location = /test1 {rewrite ^(.*)$ /xss.html break;}location = /test2 {add_header X-Content-Type-Options nosniff;rewrite ^(.*)$ /xss.html break;} }

但/test2的location中又添加了X-Content-Type-Options頭，導致付快中的add_header全部失效:

此時，test2的csp就完全失效了，我們成功觸發了XSS:

總結

Nginx配置文件造成的漏洞絕不止這三種，比如之前特別火的解析漏洞（?https://github.com/phith0n/vulhub/tree/master/nginx_parsing_vulnerability?），也和Nginx的配置有一定關系。

解決這類漏洞，

最忌去百度網上的一些解決方法，很多錯誤就是一傳十十傳百，最后流傳開來的。

另外，本文開頭提到的工具gixy，我們也可以利用起來，網站上線前進行一下掃描，也許就能發現一些可能存在的問題。

參考文章：

• http://blog.volema.com/nginx-insecurities.html
• https://github.com/phith0n/vulhub/tree/master/nginx/insecure-configuration
• https://hackerone.com/reports/25275

?

最根本的方法是仔細閱讀官方文檔，文檔里說明了很多配置文件錯誤和正確的用法。

總結

以上是生活随笔為你收集整理的三个案例看Nginx配置安全的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。