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

所以我挑選我覺得比較有趣，而且很有可能犯錯(cuò)誤的三個(gè)典型案例，來說說Nginx配置文件的安全。

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

$uri 導(dǎo)致的CRLF注入漏洞

下面兩種情景十分常見：

1. 用戶訪問 http://example.com/aabbcc ，自動(dòng)跳轉(zhuǎn)到 https://example.com/aabbcc
2. 用戶訪問 http://example.com/aabbcc ，自動(dòng)跳轉(zhuǎn)到 http://www.example.com/aabbcc

比如我的博客，訪問 http://www.leavesongs.com/other/tinger.html ，將會(huì)301跳轉(zhuǎn)到 https://www.leavesongs.com/other/tinger.html 。隨著現(xiàn)在https的普及，很多站點(diǎn)都強(qiáng)制使用https訪問，這樣的跳轉(zhuǎn)非常常見。

第二個(gè)場(chǎng)景主要是為了統(tǒng)一用戶訪問的域名，更加有益于SEO優(yōu)化。

在跳轉(zhuǎn)的過程中，我們需要保證用戶訪問的頁面不變，所以需要從Nginx獲取用戶請(qǐng)求的文件路徑。查看Nginx文檔，可以發(fā)現(xiàn)有三個(gè)表示uri的變量：

1. $uri
2. $document_uri
3. $request_uri

解釋一下，1和2表示的是解碼以后的請(qǐng)求路徑，不帶參數(shù)；3表示的是完整的URI（沒有解碼）。那么，如果運(yùn)維配置了下列的代碼：

location / {
    return 302 https://$host$uri;
}

因?yàn)?$uri 是解碼以后的請(qǐng)求路徑，所以可能就會(huì)包含換行符，也就造成了一個(gè)CRLF注入漏洞。（關(guān)于CRLF注入漏洞，可以參考我的老文章 https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html ）

這個(gè)CRLF注入漏洞可以導(dǎo)致會(huì)話固定漏洞、設(shè)置Cookie引發(fā)的CSRF漏洞或者XSS漏洞。其中，我們通過注入兩個(gè) \r\n 即可控制HTTP體進(jìn)行XSS，但因?yàn)闉g覽器認(rèn)為這是一個(gè)300跳轉(zhuǎn)，所以并不會(huì)顯示我們注入的內(nèi)容。

這個(gè)情況下，我們可以利用一些技巧：比如使用CSP頭來iframe的地址，這樣瀏覽器就不會(huì)跳轉(zhuǎn)，進(jìn)而執(zhí)行我們插入的HTML：

關(guān)于上述利用方法，可以參考我的另一篇文章《 Bottle HTTP 頭注入漏洞探究 》。

如何修復(fù)這個(gè)CRLF漏洞？正確的做法應(yīng)該是如下：

location / {
    return 302 https://$host$request_uri;
}

另外，由 $uri 導(dǎo)致的CRLF注入漏洞不僅可能出現(xiàn)在上述兩個(gè)場(chǎng)景中，理論上，只要是可以設(shè)置HTTP頭的場(chǎng)景都會(huì)出現(xiàn)這個(gè)問題。

這個(gè)常見于Nginx做反向代理的情況，動(dòng)態(tài)的部分被proxy_pass傳遞給后端端口，而靜態(tài)文件需要Nginx來處理。

假設(shè)靜態(tài)文件存儲(chǔ)在/home/目錄下，而該目錄在url中名字為files，那么就需要用alias設(shè)置目錄的別名：

location /files {
    alias /home/;
}

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

但我們注意到，url上 /files 沒有加后綴 / ，而alias設(shè)置的 /home/ 是有后綴 / 的，這個(gè) / 就導(dǎo)致我們可以從 /home/ 目錄穿越到他的上層目錄：

進(jìn)而我們獲得了一個(gè)任意文件下載漏洞。

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

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

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

但這里的繼承也有一些特性，比如add_header，子塊中配置后將會(huì)覆蓋父塊中的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頭，導(dǎo)致父塊中的add_header全部失效：

此時(shí)，test2的csp就完全失效了，我們成功觸發(fā)XSS：

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

解決這類漏洞，最根本的方法是仔細(xì)閱讀官方文檔，文檔里說明了很多配置文件錯(cuò)誤和正確的用法。最忌去百度網(wǎng)上的一些解決方法，很多錯(cuò)誤就是一傳十十傳百，最后流傳開來的。

另外，本文開頭提到的工具gixy，我們也可以利用起來，網(wǎng)站上線前進(jìn)行一下掃描，也許就能發(fā)現(xiàn)一些可能存在的問題。

 

來自：https://www.leavesongs.com/PENETRATION/nginx-insecure-configuration.html

 

標(biāo)簽： seo 安全 代碼 漏洞 域名

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。