Nginx常見的錯誤配置舉例

Nginx是當前主流的Web服務。 以下是一些最常見的錯誤配置。

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，這意味著我們可以訪問該目錄下的文件。 上面的配置沒有/的位置（location / {...}），只有/hello.txt的位置。 因此，將對root指令進行全局設置，這意味著對/的請求會將您帶到本地路徑/etc/nginx。

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

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

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配置錯誤，由于缺少/，因此有可能沿路徑上移一步。 Orange Tsai在Blackhat的演講“ Breaking Parser Logic！”中使這項技術廣為人知。 在本次演講中，他展示了location指令與alias指令結合使用的缺失斜杠如何使讀取Web應用程序的源代碼成為可能。 鮮為人知的是，它還可以與其他指令（例如proxy_pass）一起使用。 讓我們來分解一下正在發(fā)生的事情以及它為什么起作用。

  location /api {
    proxy_pass http://apiserver/v1/;
  }

如果Nginx服務器可以訪問以下配置，則可以假定只能訪問http://apiserver/v1/下的路徑。

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

當請求http://server/api/user時，Nginx將首先規(guī)范化URL。 然后，它會查看前綴/api是否與URL匹配，在這種情況下，它與URL匹配。 然后，從URL中刪除該前綴，因此保留/user路徑。 然后將此路徑添加到proxy_pass URL中，從而得到最終URL http://apiserver/v1//user。 請注意，URL中存在雙斜杠，因為location指令不以斜杠結尾，并且proxy_pass URL路徑以斜杠結尾。 大多數(shù)Web服務器會將http://apiserver/v1//user user標準化為http://apiserver/v1/user，這意味著即使配置錯誤，所有內(nèi)容仍將按預期運行，并且可能不會引起注意。

通過請求http://server/api../可以利用這種錯誤配置，這將導致Nginx請求標準化為http://apiserver/v1/../的URL http://apiserver/。 這可能產(chǎn)生的影響取決于利用這種錯誤配置可以達到的效果。 例如，這可能導致Apache服務器狀態(tài)通過URL http://server/api../server-status 公開，或者可能使不希望公開訪問的路徑可訪問。

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

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

Unsafe variable use

一些框架、腳本和Nginx配置不安全地使用Nginx存儲的變量。 這可能會導致諸如XSS，繞過HttpOnly保護，信息泄露甚至在某些情況下甚至是RCE之類的問題。

SCRIPT_NAME

如下配置：

  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結尾的PHP解釋器，即使該文件在磁盤上不存在。 這是Nginx創(chuàng)建的Pitfalls and Common Mistakes文檔中羅列的許多Nginx錯誤配置中的一種。

如果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變量有關的另一個錯誤配置是使用$uri或$document_uri而不是$request_uri。 $uri和$document_uri包含標準化的URI，而Nginx中的標準化包括對URI進行解碼的URL。 Volema 發(fā)現(xiàn)，在Nginx配置中創(chuàng)建重定向會導致CRLF注入時，通常使用$uri。

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

location / {
 return 302 https://example.com$uri;
}

HTTP請求的新行字符為\r（回車）和\n（換行）。 對新行字符進行URL編碼將導致以下字符％0d％0a的表示形式。 如果這些字符包含在對服務器的配置錯誤的請求（例如http://localhost/%0d%0aDetectify:%20clrf）中，則該服務器將使用名為Detectify的新標頭進行響應，這是因為$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

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

測試方法如下：

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

Raw backend response reading

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

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

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;
}

如果后端的響應狀態(tài)大于300， proxy_intercept_errors將提供自定義響應。在上面的uWSGI應用程序中，我們將發(fā)送500錯誤，Nginx將攔截該錯誤。

proxy_hide_header：可以隱藏任何指定的來自客戶端的HTTP標頭。

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

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: close

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

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

我們將收到以下響應：

XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info

Secret info, should not be visible!

merge_slashes set to off

默認情況下，merge_slashes指令設置為on，這是一種將兩個或多個正斜杠壓縮為一個的機制，因此///將變?yōu)?code>/。 如果Nginx用作反向代理，并且被代理的應用程序容易受到本地文件包含的影響，則在請求中使用額外的斜杠可能會留出利用空間。 Danny Robinson and Rotem Bar對此進行了詳細描述。

以上就是Nginx常見的錯誤配置舉例的詳細內(nèi)容，更多關于Nginx 錯誤配置的資料請關注腳本之家其它相關文章！