我的服務器上有一些 PHP 腳本，用于定期的 cron 作業（例如，用于每日和諧和更新排行榜）。為了防止外部人員手動運行這些腳本（http://url/script.php例如通過在瀏覽器中運行），我包含了以下代碼以在運行實際腳本之前檢查 IP 地址。其中XX.XX.XX.XX代表我自己網絡的IP地址。 $remote = isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : '127.0.0.1'; $whitelist = array('XX.XX.XX.XX', '127.0.0.1'); if (!in_array($remote, $whitelist)) { exit; } 所以現在我有以下問題：這有多安全？有什么風險？我怎樣才能使它更安全？還有其他（更好的）解決方案嗎？附言。我之前的問題已關閉，因為有人認為這個問題與PHP IP Address Whitelist with Wildcards重復。但我不是這樣的！這個問題是關于在白名單中使用通配符，而這個問題是關于這個解決方案的安全性和風險。
2 回答
不負相思意
TA貢獻1777條經驗 獲得超10個贊
所提出的方法并不完全安全。
PHP 充當文本預處理器，這意味著在 Web 服務器網關錯誤的情況下，可以使用 mime 類型的文本/html 發送腳本內容，這存在泄露敏感數據（例如 SQL 數據庫密碼或(s)ftp 帳戶。
如果腳本中控制的 IP 地址是共享（或動態傳輸）地址，則公開放置的管理腳本也存在未經授權執行的風險。Cron 腳本是使用 php-cli 執行的，因此不需要 Web 服務器網關，如果它在公共目錄之外，則不需要在腳本中進行 IP 分析。
使用 curl 等遠程執行可能是將管理腳本放置在 www 服務器公共空間的唯一原因。這通常是一個薄弱的解決方案，因為腳本會使用其他設置執行 php 解釋器（而不是 php-cli），通常執行時間非常有限。但是，如果出于某種原因有必要，它應該位于一個單獨的目錄中，該目錄的訪問僅限于使用 .htaccess（和/或 .iptables）的特定 IP 地址，并使用 htpasswd（基本身份驗證）分配的用戶名和密碼。
理想情況是當www服務器的public目錄（以下簡稱public）只包含靜態內容（img,css,js...文件），應用觸發器位于父目錄。示例結構為：
/home/username/domainname/(apps,crons,public,tmp)
apps 目錄應包含所有應用程序文件和目錄。公共目錄應該只包含靜態內容（為了在某些子目錄中排序）和指向應用程序主文件的符號鏈接，可以使用以下命令獲得：
ln -s ../apps/app.php index.php
某些服務器配置不允許使用符號鏈接。然后你可以使用包含以下內容的 index.php 文件：
<?php
include('/home/username/domainname/apps/app.php');這個解決方案有點糟糕，因為如果網關出現故障，目錄結構就會暴露。但是，敏感數據仍然是安全的，因為 Web 服務器無法顯示不存在的文件的內容。
假設 php 文件本身位于公共 Web 服務器之外，所提供的 IP 分析可用于顯示授權地址的部分內容。但是，如果這些是整個網站，我更愿意使用 iptables 或 .htaccess 來管理對它們的訪問。
神不在的星期二
TA貢獻1963條經驗 獲得超6個贊
這有多安全？
實際上，只要您控制地址（127.0.0.1 可以，XXX.XXX.XXX.XXX 可能不行），它就非常安全。我所說的相當安全的意思是，有人濫用該系統的可能性很小，濫用 Web 應用程序其余部分的可能性也不大。
有什么風險？
有人可能會從外部調用您的腳本，如果他們有辦法以某種方式假設 IP 地址 XXX.XXX.XXX.XXX，或者欺騙 systemm 相信他們有。
我怎樣才能使它更安全？
您可以在原始調用中包含一個秘密，并根據同一秘密的哈希值對其進行檢查。即使有人能讀懂劇本，秘密也不會泄露。
if (!array_key_exists('key', $_GET)) {
die('Access denied');
}
if (sha1($_GET['key']) !== '713dca7cf928f23a2347cae828d98879629e1e80') {
die('Access denied');
}
也可以將腳本放在web根目錄之外require，通過語句調用。這樣，要么 PHP 子系統工作，腳本無法讀取，要么不工作，顯示的只是一個無法訪問的目錄的名稱。您甚至可以合并這兩種方法：
if (sha1($_GET['key']) !== '713dca7cf928f23a2347cae828d98879629e1e80') {
die('Access denied');
}
$realScript = $_GET['key'];
require $realScript;
現在，唯一可以包含的腳本是名稱具有特定 SHA1 哈希的腳本，沒有其他腳本（沖突的風險實際上可以忽略不計：您需要與有效文件名發生沖突，以及創建此類文件名的方法). 所以你知道腳本是有效的，但除非在調用中提供名稱，否則整個構造將無法工作，它甚至不會告訴攻擊者原因。
curl http://yoursite.internal.address/cron/cron.php?key=../scripts7ab9ceef/mycron.php
還有其他（更好的）解決方案嗎？
是和不是。使用命令行界面調用腳本同樣安全，并且不需要工作的網絡服務器。如果需要，它還允許以不同的用戶身份運行。
另一方面，它需要安裝一個命令行界面，這可能會產生其他安全問題，即使使用相同的用戶和主目錄，這兩個界面的行為仍然可能有微妙的不同（或不那么微妙：你可能有一個 PHP7.3 Web 模塊和一個 PHP5.2 CLI 安裝，反之亦然，這將使具有短數組語法（或具有類似結構if(empty(some_function($_GET['x']))）的腳本甚至無法加載到一個或另一個界面中。
總而言之，對curlor 的crontab 調用lynx可能更易于維護和使用，即使它無疑效率較低。
- 2 回答
- 0 關注
- 132 瀏覽
添加回答
舉報
0/150
提交
取消