始終使用=== and！ ==為避免比較中的意外類型強制，==可能會導致諸如身份驗證旁路之類的安全缺陷。 2。使用hash_equals（）比較密碼哈希或令牌以防止0E科學符號利用。 3。避免在陣列鍵和開關情況下混合類型，因為PHP將“ 0”和0視為相同，導致了意外的行為。 4。使用filter_var（）或嚴格的類型提示從$ _ post，$ _get或API中明確驗證和驗證輸入，以防止虛假的字符串評估。 5。啟用聲明（strict_types = 1）;並使用鍵入參數來強制類型安全性。最重要的是，PHP的打字雖然方便，但卻引入了實際的安全風險和錯誤，因此開發(fā)人員必須執(zhí)行嚴格的比較，驗證輸入和控制類型，並明確處理以防止漏洞。

PHP的鬆散類型雜耍是那些一開始會感覺方便的功能之一，但如果您不小心，很快就會成為雷區(qū)。雖然它允許靈活的比較和易於可變處理，但它也引入了很難捕獲的微妙錯誤和安全漏洞。這是真正的危險及其如何咬您的細分。

1。在比較中類型強制（== vs ===）

最常見的陷阱是使用鬆散的比較（ == ）而不是嚴格的比較（ === ）。

如果（'0'== false）{
    迴聲“這運行！”；
}

即使'0'是字符串， false是布爾值，但PHP還是將其轉換為常見類型。由於字符串'0'被認為是“虛擬”，因此將其評估為true 。但這很少是您想要的。

為什麼這很危險：

• 身份驗證旁路： '0' == 0可能允許旁路檢查if ($user->isAdmin != 1)
• 輸入驗證失?。?'1abc' == 1返回true ，因為PHP從字符串中提取數字

?修復：始終使用=== and !==當類型很重要時。

2。哈希比較漏洞

一個經典的示例涉及使用鬆散平等比較密碼哈希。

 $ endure ='0E123456'; //例如，以“ 0”開頭的哈希
$ user_input ='0E999999';

如果（$ endure == $ user_input）{
    // PHP將其視為科學符號：0×10^123456→0
    //因此雙方變?yōu)?→比較是正確的！
    迴聲“授予訪問權！”；
}

如果兩個字符串以0e開頭，則PHP將它們解釋為科學符號中的數字 - 並且由於任何0eN等於0，因此它們被認為是平等的。

影響：

• 這導致了密碼重置令牌或API鍵中的現實世界漏洞
• 與==進行比較或令牌的系統可以被欺騙到將不同的字符串視為平等的系統

?修復：使用hash_equals()進行定時安全性，嚴格的琴弦比較。

3。陣列和切換語句中的意外行為

PHP的類型雜耍也會影響switch和數組鍵訪問。

 $ array = ['0'=>'零'，0 =>'整數零'];
var_dump（$ array）; //只有一個元素：[0 =>'整數零']

字符串'0'和整數0被視為相同的鍵。

在switch語句中：

 $角色='admin';
switch（$ cole）{
    情況0：
        迴聲“訪客訪問”； //這不會運行，但是很容易誤讀
        休息;
}

但是，如果$role = '0admin' ，則PHP在數字上下文中將其轉換為0 ，並且情況觸發(fā)了情況。

?修復：避免在鍵和案例語句中混合類型。早期驗證輸入類型。

4。表格和API輸入處理風險

用戶通過$_GET ， $_POST或json輸入始終是字符串。當您在不投射的情況下比較或進行操作時，出現問題。

 if（$ _post ['age'] == 25）{
    //'25abc'== 25→true！ PHP將“ 25ABC”轉換為25
    //如此無效的輸入通過
}

這是由於PHP提取數字前綴並丟棄其餘的。

?最佳實踐：

• 明確鑄造： (int)$_POST['age'] === 25
• 使用filter_var()驗證：

   if（filter_var（$ _ post ['age']，filter_validate_int）=== 25）

• 在功能中使用嚴格的鍵入：

  功能固定（int $ age）{...}

  ---

  底線

  PHP的鬆散鍵入可以節(jié)省簡單腳本的時間，但是在實際應用程序中，這是一個責任。這些問題不僅是學術，而且導致了CVE和安全漏洞。

  關鍵要點：

  • use === and !==默認情況下
  • 將hash_equals()用於秘密
  • 提早施放和驗證輸入
  • 啟用嚴格的鍵入： declare(strict_types=1);在文件中使用鍵入功能

  並不是說PHP被打破了，而是默認值太寬容了。一旦了解了PHP的雜耍類型，就可以通過控製過程來編寫更安全的代碼，而不是將其留給猜測。

  基本上，假設PHP會嘗試提供幫助 - 並且“幫助”可能會破壞您的應用程序。

  以上是PHP鬆散類型的雜耍的隱藏危險的詳細內容。更多資訊請關注PHP中文網其他相關文章！