Nginx 錯(cuò)誤配置如果不能及時(shí)修正,它會(huì)讓你的網(wǎng)站陷入網(wǎng)絡(luò)攻擊的風(fēng)險(xiǎn)。
作為互聯(lián)網(wǎng)上最常用的 Web 服務(wù)器之一,Nginx 因輕巧、模塊化并且有對(duì)用戶友好的配置格式而廣受歡迎。Detectify 使用 Google BigQuery 分析了從 GitHub 下載的近 50000 個(gè)不重復(fù)的 Nginx 配置文件。
本文主要關(guān)注以下常見的 Nginx 錯(cuò)誤配置:
根目錄位置丟失
off-by-slash
不安全的變量使用
原始后端響應(yīng)讀取
merge_slashes
設(shè)置為 off
server {
root /etc/nginx;
location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}
root 指令指定 Nginx 的根文件夾。在上面的示例中,根文件夾是/etc/nginx
,這意味著我們可以訪問該文件夾中的文件。上面的配置沒有針對(duì)/ (location / {...})
的位置,只有/hello.txt
的位置。因此,root 指令會(huì)被設(shè)置為全局,這意味著對(duì)/
的請(qǐng)求會(huì)將你帶到本地路徑/etc/nginx
。
像GET /nginx.conf
這樣簡(jiǎn)單的請(qǐng)求都能顯示存儲(chǔ)在 /etc/nginx/nginx.conf
中 Nginx 配置文件的內(nèi)容。如果將根設(shè)置為/etc
,則對(duì)/nginx/nginx.conf
的GET
請(qǐng)求將顯示配置文件。在某些情況下,訪問者可能會(huì)訪問其他配置文件、訪問日志甚至 HTTP 基本身份驗(yàn)證的加密憑據(jù)。
在我們收集的近 50000 個(gè) Nginx 配置文件中,最常見的根路徑如下:
經(jīng)常配置錯(cuò)誤的 Nginx 根路徑
server {
listen 80 default_server;
server_name _;
location /static {
alias /usr/share/nginx/static/;
}
location /api {
proxy_pass http://apiserver/v1/;
}
}
這個(gè)配置錯(cuò)誤指的是由于缺少一個(gè)斜杠,所以有可能沿路徑上移一步。OrangeTsai 在 Blackhat 演講“Breaking Parser Logic!”中讓這項(xiàng)技術(shù)廣為人知。
https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf
在這個(gè)演講中,他展示了如何結(jié)合一條缺少尾斜杠的location
指令與一條alias
指令,來讀取 Web 應(yīng)用程序的源代碼。鮮為人知的是,它還可以與其他指令(例如proxy_pass
)一起使用。我們來分解一下究竟發(fā)生了什么事情,以及為什么它能起作用。
location /api {
proxy_pass http://apiserver/v1/;
}
如果一個(gè) Nginx 服務(wù)器運(yùn)行能在 server 訪問的以下配置,則可以假定訪問者只能訪問http://apiserver/v1/
下的路徑。
http://server/api/user -> http://apiserver/v1//user
當(dāng)請(qǐng)求http://server/api/user
時(shí),Nginx 將首先規(guī)范化 URL。然后,它會(huì)查看前綴 /api
是否與 URL 匹配,本例中是匹配的。
然后,服務(wù)器從 URL 中刪除該前綴,保留/user
路徑。再將此路徑添加到proxy_pass
URL 中,從而得到最終 URL http://apiserver/v1//user
。
請(qǐng)注意,這個(gè) URL 中存在雙斜杠,因?yàn)?location 指令不以單斜杠結(jié)尾,并且proxy_pass
URL 路徑以單斜杠結(jié)尾。大多數(shù) Web 服務(wù)器會(huì)將http://apiserver/v1//user
標(biāo)準(zhǔn)化為http://apiserver/v1/user
,這意味著即使配置錯(cuò)誤,所有內(nèi)容仍將按預(yù)期運(yùn)行,并且可能不會(huì)引起注意。請(qǐng)求http://server/api../
可以利用這種錯(cuò)誤配置,這將導(dǎo)致 Nginx 請(qǐng)求 URL http://apiserver/v1/../
,其標(biāo)準(zhǔn)化為http://apiserver/
。這可能產(chǎn)生的影響取決于利用這種錯(cuò)誤配置可以達(dá)到的效果。例如,這可能導(dǎo)致 Apache 服務(wù)器狀態(tài)通過 URL http://server/api../server-status
公開,或者可能讓不希望公開訪問的路徑可訪問。
Nginx 服務(wù)器配置錯(cuò)誤的一個(gè)跡象是,當(dāng) URL 中的一個(gè)斜杠被刪除時(shí),服務(wù)器仍會(huì)返回相同的響應(yīng)。例如,如果http://server/api/user
和http://server/apiuser
返回相同的響應(yīng),則服務(wù)器可能容易受到攻擊。這將導(dǎo)致發(fā)送以下請(qǐng)求:
http://server/api/user -> http://apiserver/v1//user
http://server/apiuser -> http://apiserver/v1/user
一些框架、腳本和 Nginx 配置會(huì)不安全地使用 Nginx 存儲(chǔ)的變量。這可能會(huì)導(dǎo)致諸如 XSS、繞過 HttpOnly 保護(hù)、信息泄露,甚至在某些情況下的 RCE 之類的問題。
像下面這樣的配置:
location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; }
主要問題是 Nginx 會(huì)將所有 URL 發(fā)送到以.php
結(jié)尾的 PHP 解釋器,即使該文件在磁盤上不存在。這是 Nginx 創(chuàng)建的“陷阱和常見錯(cuò)誤”文檔中提到的,在許多 Nginx 配置中都常見的錯(cuò)誤。
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php?fileGuid=xVX6hcx8WXCYPVGd
如果這個(gè) PHP 腳本試圖基于SCRIPT_NAME
定義一個(gè)基本 URL,則將發(fā)生 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 變量有關(guān)的另一個(gè)錯(cuò)誤配置是使用$uri
或$document_uri
代替$request_uri
。$uri
和$document_uri
包含標(biāo)準(zhǔn)化的 URI,而 Nginx 中的normalization
包括對(duì) URI 解碼的 URL。Volema 發(fā)現(xiàn),在 Nginx 配置中創(chuàng)建重定向時(shí)經(jīng)常會(huì)使用$uri
,結(jié)果導(dǎo)致 CRLF 注入。
一個(gè)易受攻擊的 Nginx 配置的示例如下:
location / {return 302 https://example.com$uri;}
HTTP 請(qǐng)求的換行符為\r(回車)和\n(換行)。對(duì)換行符進(jìn)行 URL 編碼將導(dǎo)致以下字符表示形式%0d%0a
。如果將這些字符包含在對(duì)配置錯(cuò)誤的服務(wù)器的一個(gè)請(qǐng)求中(例如http://localhost/%0d%0aDetectify:%20clrf
),則該服務(wù)器將使用一個(gè)名為Detectify
的新標(biāo)頭進(jìn)行響應(yīng),因?yàn)?$uri 變量包含 URL 解碼的換行符。
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf
在某些情況下,用戶提供的數(shù)據(jù)可以視為 Nginx 變量。目前尚不清楚為什么會(huì)發(fā)生這種情況,但如這份 H1 報(bào)告所示,這種情況并不罕見或不容易測(cè)試。如果搜索錯(cuò)誤消息,我們可以看到它是在 SSI 過濾器模塊中找到的,表明這是由 SSI 引起的。
https://hackerone.com/reports/370094?fileGuid=xVX6hcx8WXCYPVGd
一種測(cè)試方法是設(shè)置一個(gè)引用標(biāo)頭值:
$ curl -H 'Referer: bar’ http://localhost/foo$http_referer | grep 'foobar’
我們掃描了這種錯(cuò)誤配置,發(fā)現(xiàn)了幾個(gè)實(shí)例,用戶可以在其中打印 Nginx 變量的值。我們發(fā)現(xiàn)易受攻擊實(shí)例的數(shù)量有所下降,這可能表明這個(gè)漏洞已經(jīng)做了修補(bǔ)。
使用 Nginx 的proxy_pass
,可以攔截后端創(chuàng)建的錯(cuò)誤和 HTTP 標(biāo)頭。如果你要隱藏內(nèi)部錯(cuò)誤消息和標(biāo)頭以便 Nginx 處理,這個(gè)方法會(huì)非常有用。如果后端回答一個(gè)錯(cuò)誤,Nginx 將自動(dòng)提供一個(gè)自定義錯(cuò)誤頁面。但如果 Nginx 無法理解這是一個(gè) HTTP 響應(yīng)怎么辦?
如果一個(gè)客戶端向 Nginx 發(fā)送了一個(gè)無效的 HTTP 請(qǐng)求,則該請(qǐng)求將按原樣轉(zhuǎn)發(fā)到后端,后端將使用其原始內(nèi)容來應(yīng)答。然后,Nginx 將無法理解無效的 HTTP 響應(yīng),而將其轉(zhuǎn)發(fā)給客戶端。想象一個(gè)這樣的 uWSGI 應(yīng)用程序:
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;}
如果后端的響應(yīng)狀態(tài)大于 300,proxy_intercept_errors 將提供一個(gè)自定義響應(yīng)。在上面的 uWSGI 應(yīng)用程序中,我們將發(fā)送一個(gè)500 Error
,Nginx 將攔截該錯(cuò)誤。
proxy_hide_header 可以自解釋;它將從客戶端隱藏任何指定的 HTTP 標(biāo)頭。
如果我們發(fā)送一個(gè)普通的 GET 請(qǐng)求,則 Nginx 將返回:
HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: close
但是,如果我們發(fā)送一個(gè)無效的 HTTP 請(qǐng)求,例如:
GET /? XTTP/1.1Host: 127.0.0.1Connection: close
我們將收到以下答復(fù):
XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info
Secret info, should not be visible!
默認(rèn)情況下,merge_slashes 指令設(shè)置為“on”,這是一種將兩個(gè)或多個(gè)正斜杠壓縮為一個(gè)的機(jī)制,因此///
將變?yōu)?code>/。如果 Nginx 用作反向代理,并且被代理的應(yīng)用程序容易受到本地文件包含內(nèi)容的影響,則在請(qǐng)求中使用額外的斜杠可能會(huì)留出惡意利用空間。
http://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes?fileGuid=xVX6hcx8WXCYPVGd
我們發(fā)現(xiàn) 33 個(gè) Nginx 配置文件的merge_slashes
設(shè)置為“off”。
我們創(chuàng)建了一個(gè) GitHub 存儲(chǔ)庫,你可以在其中使用 Docker 來設(shè)置你自己的易受攻擊的 Nginx 測(cè)試服務(wù)器,以及本文中討論的一些錯(cuò)誤配置,然后嘗試自己找到它們。
https://github.com/detectify/vulnerable-nginx?fileGuid=xVX6hcx8WXCYPVGd
Nginx 是一個(gè)非常強(qiáng)大的 Web 服務(wù)器平臺(tái),很好理解為什么它會(huì)被廣泛使用。但是,靈活的配置意味著你更容易犯錯(cuò)誤,而這些錯(cuò)誤可能會(huì)對(duì)安全性產(chǎn)生影響。請(qǐng)不要使用這些常見的錯(cuò)誤配置,以免攻擊者輕易地入侵你的網(wǎng)站。
原文鏈接:
https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/?fileGuid=xVX6hcx8WXCYPVGd
聯(lián)系客服