Nginx 錯誤配置如果不能及時修正，它會讓你的網(wǎng)站陷入網(wǎng)絡(luò)攻擊的風(fēng)險。

作為互聯(lián)網(wǎng)上最常用的 Web 服務(wù)器之一，Nginx 因輕巧、模塊化并且有對用戶友好的配置格式而廣受歡迎。Detectify 使用 Google BigQuery 分析了從 GitHub 下載的近 50000 個不重復(fù)的 Nginx 配置文件。

本文主要關(guān)注以下常見的 Nginx 錯誤配置：

• 根目錄位置丟失

• off-by-slash
  

• 不安全的變量使用

• 原始后端響應(yīng)讀取

• merge_slashes設(shè)置為 off

root 指令指定 Nginx 的根文件夾。在上面的示例中，根文件夾是/etc/nginx，這意味著我們可以訪問該文件夾中的文件。上面的配置沒有針對/ (location / {...})的位置，只有/hello.txt的位置。因此，root 指令會被設(shè)置為全局，這意味著對/的請求會將你帶到本地路徑/etc/nginx。

像GET /nginx.conf這樣簡單的請求都能顯示存儲在 /etc/nginx/nginx.conf中 Nginx 配置文件的內(nèi)容。如果將根設(shè)置為/etc，則對/nginx/nginx.conf的GET請求將顯示配置文件。在某些情況下，訪問者可能會訪問其他配置文件、訪問日志甚至 HTTP 基本身份驗證的加密憑據(jù)。

在我們收集的近 50000 個 Nginx 配置文件中，最常見的根路徑如下：

經(jīng)常配置錯誤的 Nginx 根路徑

server {        listen 80 default_server;
        server_name _;
        location /static {                alias /usr/share/nginx/static/;        }
        location /api {                proxy_pass http://apiserver/v1/;        }}

這個配置錯誤指的是由于缺少一個斜杠，所以有可能沿路徑上移一步。OrangeTsai 在 Blackhat 演講“Breaking Parser Logic!”中讓這項技術(shù)廣為人知。

https://i./us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf

在這個演講中，他展示了如何結(jié)合一條缺少尾斜杠的location指令與一條alias指令，來讀取 Web 應(yīng)用程序的源代碼。鮮為人知的是，它還可以與其他指令（例如proxy_pass）一起使用。我們來分解一下究竟發(fā)生了什么事情，以及為什么它能起作用。

如果一個 Nginx 服務(wù)器運行能在 server 訪問的以下配置，則可以假定訪問者只能訪問http://apiserver/v1/下的路徑。

http://server/api/user -> http://apiserver/v1//user

當(dāng)請求http://server/api/user時，Nginx 將首先規(guī)范化 URL。然后，它會查看前綴 /api是否與 URL 匹配，本例中是匹配的。

然后，服務(wù)器從 URL 中刪除該前綴，保留/user路徑。再將此路徑添加到proxy_passURL 中，從而得到最終 URL http://apiserver/v1//user。

請注意，這個 URL 中存在雙斜杠，因為 location 指令不以單斜杠結(jié)尾，并且proxy_pass URL 路徑以單斜杠結(jié)尾。大多數(shù) Web 服務(wù)器會將http://apiserver/v1//user標(biāo)準(zhǔn)化為http://apiserver/v1/user，這意味著即使配置錯誤，所有內(nèi)容仍將按預(yù)期運行，并且可能不會引起注意。請求http://server/api../可以利用這種錯誤配置，這將導(dǎo)致 Nginx 請求 URL http://apiserver/v1/../，其標(biāo)準(zhǔn)化為http://apiserver/。這可能產(chǎn)生的影響取決于利用這種錯誤配置可以達(dá)到的效果。例如，這可能導(dǎo)致 Apache 服務(wù)器狀態(tài)通過 URL http://server/api../server-status公開，或者可能讓不希望公開訪問的路徑可訪問。

Nginx 服務(wù)器配置錯誤的一個跡象是，當(dāng) URL 中的一個斜杠被刪除時，服務(wù)器仍會返回相同的響應(yīng)。例如，如果http://server/api/user和http://server/apiuser返回相同的響應(yīng)，則服務(wù)器可能容易受到攻擊。這將導(dǎo)致發(fā)送以下請求：

一些框架、腳本和 Nginx 配置會不安全地使用 Nginx 存儲的變量。這可能會導(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 會將所有 URL 發(fā)送到以.php結(jié)尾的 PHP 解釋器，即使該文件在磁盤上不存在。這是 Nginx 創(chuàng)建的“陷阱和常見錯誤”文檔中提到的，在許多 Nginx 配置中都常見的錯誤。

https://www./resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php?fileGuid=xVX6hcx8WXCYPVGd

如果這個 PHP 腳本試圖基于SCRIPT_NAME定義一個基本 URL，則將發(fā)生 XSS。

與 Nginx 變量有關(guān)的另一個錯誤配置是使用$uri或$document_uri代替$request_uri。$uri和$document_uri包含標(biāo)準(zhǔn)化的 URI，而 Nginx 中的normalization包括對 URI 解碼的 URL。Volema 發(fā)現(xiàn)，在 Nginx 配置中創(chuàng)建重定向時經(jīng)常會使用$uri，結(jié)果導(dǎo)致 CRLF 注入。

一個易受攻擊的 Nginx 配置的示例如下：

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

HTTP 請求的換行符為\r（回車）和\n（換行）。對換行符進(jìn)行 URL 編碼將導(dǎo)致以下字符表示形式％0d％0a。如果將這些字符包含在對配置錯誤的服務(wù)器的一個請求中（例如http://localhost/％0d％0aDetectify:％20clrf），則該服務(wù)器將使用一個名為Detectify的新標(biāo)頭進(jìn)行響應(yīng)，因為 $uri 變量包含 URL 解碼的換行符。

在某些情況下，用戶提供的數(shù)據(jù)可以視為 Nginx 變量。目前尚不清楚為什么會發(fā)生這種情況，但如這份 H1 報告所示，這種情況并不罕見或不容易測試。如果搜索錯誤消息，我們可以看到它是在 SSI 過濾器模塊中找到的，表明這是由 SSI 引起的。

https:///reports/370094?fileGuid=xVX6hcx8WXCYPVGd

一種測試方法是設(shè)置一個引用標(biāo)頭值：

$ curl -H 'Referer: bar’ http://localhost/foo$http_referer | grep 'foobar’

我們掃描了這種錯誤配置，發(fā)現(xiàn)了幾個實例，用戶可以在其中打印 Nginx 變量的值。我們發(fā)現(xiàn)易受攻擊實例的數(shù)量有所下降，這可能表明這個漏洞已經(jīng)做了修補。

使用 Nginx 的proxy_pass，可以攔截后端創(chuàng)建的錯誤和 HTTP 標(biāo)頭。如果你要隱藏內(nèi)部錯誤消息和標(biāo)頭以便 Nginx 處理，這個方法會非常有用。如果后端回答一個錯誤，Nginx 將自動提供一個自定義錯誤頁面。但如果 Nginx 無法理解這是一個 HTTP 響應(yīng)怎么辦？

如果一個客戶端向 Nginx 發(fā)送了一個無效的 HTTP 請求，則該請求將按原樣轉(zhuǎn)發(fā)到后端，后端將使用其原始內(nèi)容來應(yīng)答。然后，Nginx 將無法理解無效的 HTTP 響應(yīng)，而將其轉(zhuǎn)發(fā)給客戶端。想象一個這樣的 uWSGI 應(yīng)用程序：

并在 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 Error，Nginx 將攔截該錯誤。

proxy_hide_header 可以自解釋；它將從客戶端隱藏任何指定的 HTTP 標(biāo)頭。

如果我們發(fā)送一個普通的 GET 請求，則 Nginx 將返回：

但是，如果我們發(fā)送一個無效的 HTTP 請求，例如：

GET /? XTTP/1.1Host: 127.0.0.1Connection: close

我們將收到以下答復(fù)：

默認(rèn)情況下，merge_slashes 指令設(shè)置為“on”，這是一種將兩個或多個正斜杠壓縮為一個的機(jī)制，因此///將變?yōu)?code>/。如果 Nginx 用作反向代理，并且被代理的應(yīng)用程序容易受到本地文件包含內(nèi)容的影響，則在請求中使用額外的斜杠可能會留出惡意利用空間。

http:///en/docs/http/ngx_http_core_module.html#merge_slashes?fileGuid=xVX6hcx8WXCYPVGd

我們發(fā)現(xiàn) 33 個 Nginx 配置文件的merge_slashes設(shè)置為“off”。

我們創(chuàng)建了一個 GitHub 存儲庫，你可以在其中使用 Docker 來設(shè)置你自己的易受攻擊的 Nginx 測試服務(wù)器，以及本文中討論的一些錯誤配置，然后嘗試自己找到它們。

https://github.com/detectify/vulnerable-nginx?fileGuid=xVX6hcx8WXCYPVGd

Nginx 是一個非常強(qiáng)大的 Web 服務(wù)器平臺，很好理解為什么它會被廣泛使用。但是，靈活的配置意味著你更容易犯錯誤，而這些錯誤可能會對安全性產(chǎn)生影響。請不要使用這些常見的錯誤配置，以免攻擊者輕易地入侵你的網(wǎng)站。

原文鏈接：

https://blog./2020/11/10/common-nginx-misconfigurations/?fileGuid=xVX6hcx8WXCYPVGd