Nginx常見(jiàn)的錯(cuò)誤配置舉例
Nginx是當(dāng)前主流的Web服務(wù)。 以下是一些最常見(jiàn)的錯(cuò)誤配置。
Missing root location
server { root /etc/nginx; location /hello.txt { try_files $uri $uri/ =404; proxy_pass http://127.0.0.1:8080/; } }
root
指令指定Nginx的根目錄。 在上面的示例中,根目錄是/etc/nginx,這意味著我們可以訪問(wèn)該目錄下的文件。 上面的配置沒(méi)有/
的位置(location / {...}
),只有/hello.txt的位置。 因此,將對(duì)root指令進(jìn)行全局設(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ì)訪問(wèn)其他配置文件,訪問(wèn)日志甚至HTTP基本身份驗(yàn)證的加密憑據(jù)。
在我們收集的近50,000個(gè)Nginx配置文件中,最常見(jiàn)的根路徑如下:
Off-By-Slash
server { listen 80 default_server; server_name _; location /static { alias /usr/share/nginx/static/; } location /api { proxy_pass http://apiserver/v1/; } }
借助Off-by-slash配置錯(cuò)誤,由于缺少/,因此有可能沿路徑上移一步。 Orange Tsai在Blackhat的演講“ Breaking Parser Logic!”中使這項(xiàng)技術(shù)廣為人知。 在本次演講中,他展示了location指令與alias指令結(jié)合使用的缺失斜杠如何使讀取Web應(yīng)用程序的源代碼成為可能。 鮮為人知的是,它還可以與其他指令(例如proxy_pass)一起使用。 讓我們來(lái)分解一下正在發(fā)生的事情以及它為什么起作用。
location /api { proxy_pass http://apiserver/v1/; }
如果Nginx服務(wù)器可以訪問(wèn)以下配置,則可以假定只能訪問(wèn)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匹配,在這種情況下,它與URL匹配。 然后,從URL中刪除該前綴,因此保留/user路徑。 然后將此路徑添加到proxy_pass
URL中,從而得到最終URL http://apiserver/v1//user。 請(qǐng)注意,URL中存在雙斜杠,因?yàn)閘ocation指令不以斜杠結(jié)尾,并且proxy_pass
URL路徑以斜杠結(jié)尾。 大多數(shù)Web服務(wù)器會(huì)將http://apiserver/v1//user user標(biāo)準(zhǔn)化為http://apiserver/v1/user,這意味著即使配置錯(cuò)誤,所有內(nèi)容仍將按預(yù)期運(yùn)行,并且可能不會(huì)引起注意。
通過(guò)請(qǐng)求http://server/api../可以利用這種錯(cuò)誤配置,這將導(dǎo)致Nginx請(qǐng)求標(biāo)準(zhǔn)化為http://apiserver/v1/../的URL http://apiserver/。 這可能產(chǎn)生的影響取決于利用這種錯(cuò)誤配置可以達(dá)到的效果。 例如,這可能導(dǎo)致Apache服務(wù)器狀態(tài)通過(guò)URL http://server/api../server-status 公開(kāi),或者可能使不希望公開(kāi)訪問(wèn)的路徑可訪問(wèn)。
Nginx服務(wù)器配置錯(cuò)誤的一個(gè)跡象是,當(dāng)URL中的斜杠被刪除時(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
Unsafe variable use
一些框架、腳本和Nginx配置不安全地使用Nginx存儲(chǔ)的變量。 這可能會(huì)導(dǎo)致諸如XSS,繞過(guò)HttpOnly保護(hù),信息泄露甚至在某些情況下甚至是RCE之類(lèi)的問(wèn)題。
SCRIPT_NAME
如下配置:
location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; }
主要問(wèn)題是Nginx會(huì)將所有URL發(fā)送到以.php結(jié)尾的PHP解釋器,即使該文件在磁盤(pán)上不存在。 這是Nginx創(chuàng)建的Pitfalls and Common Mistakes文檔中羅列的許多Nginx錯(cuò)誤配置中的一種。
如果PHP腳本試圖基于SCRIPT_NAME定義基本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
Usage of $uri can lead to CRLF Injection
與Nginx變量有關(guān)的另一個(gè)錯(cuò)誤配置是使用$uri或$document_uri而不是$request_uri。 $uri和$document_uri包含標(biāo)準(zhǔn)化的URI,而Nginx中的標(biāo)準(zhǔn)化包括對(duì)URI進(jìn)行解碼的URL。 Volema 發(fā)現(xiàn),在Nginx配置中創(chuàng)建重定向會(huì)導(dǎo)致CRLF注入時(shí),通常使用$uri。
易受攻擊的Nginx配置的示例如下:
location / { return 302 https://example.com$uri; }
HTTP請(qǐng)求的新行字符為\r
(回車(chē))和\n
(換行)。 對(duì)新行字符進(jìn)行URL編碼將導(dǎo)致以下字符%0d%0a
的表示形式。 如果這些字符包含在對(duì)服務(wù)器的配置錯(cuò)誤的請(qǐng)求(例如http://localhost/%0d%0aDetectify:%20clrf)中,則該服務(wù)器將使用名為Detectify的新標(biāo)頭進(jìn)行響應(yīng),這是因?yàn)?code>$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
Any variable
在某些情況下,用戶(hù)提供的數(shù)據(jù)可以視為Nginx變量。 目前尚不清楚為什么會(huì)發(fā)生這種情況,但如本H1報(bào)告所示,這種情況并不罕見(jiàn)或不容易測(cè)試。 如果搜索錯(cuò)誤消息,我們可以看到它在 SSI filter module中找到,從而表明這是由于SSI引起的。
測(cè)試方法如下:
$ curl -H ‘Referer: bar' http://localhost/foo$http_referer | grep ‘foobar'
Raw backend response reading
使用Nginx的proxy_pass
,可以攔截后端創(chuàng)建的錯(cuò)誤和HTTP標(biāo)頭。 如果要隱藏內(nèi)部錯(cuò)誤消息和標(biāo)頭,以便由Nginx處理,則這非常有用。 如果后端響應(yīng)一個(gè)請(qǐng)求,Nginx將自動(dòng)提供一個(gè)自定義錯(cuò)誤頁(yè)面。 但是,如果Nginx無(wú)法理解這是HTTP響應(yīng)怎么辦?
如果客戶(hù)端向Nginx發(fā)送無(wú)效的HTTP請(qǐng)求,則該請(qǐng)求將按原樣轉(zhuǎn)發(fā)到后端,后端將使用其原始內(nèi)容進(jìn)行應(yīng)答。 然后,Nginx將無(wú)法理解無(wú)效的HTTP響應(yīng),而會(huì)將其轉(zhuǎn)發(fā)給客戶(hù)端。 想象一下這樣的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將提供自定義響應(yīng)。在上面的uWSGI應(yīng)用程序中,我們將發(fā)送500錯(cuò)誤,Nginx將攔截該錯(cuò)誤。
proxy_hide_header:可以隱藏任何指定的來(lái)自客戶(hù)端的HTTP標(biāo)頭。
如果我們發(fā)送普通的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ā)送無(wú)效的HTTP請(qǐng)求,例如:
GET /? XTTP/1.1 Host: 127.0.0.1 Connection: close
我們將收到以下響應(yīng):
XTTP/1.1 500 Error Content-Type: text/html Secret-Header: secret-info Secret info, should not be visible!
merge_slashes set to off
默認(rèn)情況下,merge_slashes
指令設(shè)置為on
,這是一種將兩個(gè)或多個(gè)正斜杠壓縮為一個(gè)的機(jī)制,因此///
將變?yōu)?code>/。 如果Nginx用作反向代理,并且被代理的應(yīng)用程序容易受到本地文件包含的影響,則在請(qǐng)求中使用額外的斜杠可能會(huì)留出利用空間。 Danny Robinson and Rotem Bar對(duì)此進(jìn)行了詳細(xì)描述。
以上就是Nginx常見(jiàn)的錯(cuò)誤配置舉例的詳細(xì)內(nèi)容,更多關(guān)于Nginx 錯(cuò)誤配置的資料請(qǐng)關(guān)注本站其它相關(guān)文章!
版權(quán)聲明:本站文章來(lái)源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有,歡迎引用、轉(zhuǎn)載,請(qǐng)保持原文完整并注明來(lái)源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站,禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像,否則將依法追究法律責(zé)任。本站部分內(nèi)容來(lái)源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來(lái),僅供學(xué)習(xí)參考,不代表本站立場(chǎng),如有內(nèi)容涉嫌侵權(quán),請(qǐng)聯(lián)系alex-e#qq.com處理。