PHP 安全問題入門：10 個常見安全問題 + 實例講解

文章轉自：https://learnku.com/php/t/24930

更多文章：https://learnku.com/laravel/c...

相對於其他幾種語言來說， PHP 在 web 建站方面有更大的優勢，即使是新手，也能很容易搭建一個網站出來。但這種優勢也容易帶來一些負面影響，因爲很多的 PHP 教程沒有涉及到安全方面的知識。

此帖子分爲幾部分，每部分會涵蓋不同的安全威脅和應對策略。但是，這並不是說你做到這幾點以後，就一定能避免你的網站出現任何問題。如果你想提高你的網站安全性的話，你應該繼續通過閱讀書籍或者文章，來研究如何提高你的網站安全性

出於演示需要，代碼可能不是很完美。日常開發過程中，很多代碼都包含在了框架跟各種庫裏面。作爲一個後臺開發，你不僅要熟練基本的CURD，更要知道如何保護你的數據。

1. SQL 注入

我賭一包辣條，你肯定會看到這裏。 SQL 注入是對您網站最大的威脅之一，如果您的數據庫受到別人的 SQL 注入的攻擊的話，別人可以轉出你的數據庫，也許還會產生更嚴重的後果。

網站要從數據庫中獲取動態數據，就必須執行 SQL 語句，舉例如下：

<?php

$username = $_GET['username'];
$query = "SELECT * FROM users WHERE username = '$username'";

攻擊者控制通過 GET 和 POST 發送的查詢（或者例如 UA 的一些其他查詢）。一般情況下，你希望查詢戶名爲「 peter 」的用戶產生的 SQL 語句如下：

SELECT * FROM users WHERE username = 'peter'

但是，攻擊者發送了特定的用戶名參數，例如：' OR '1'='1

這就會導致 SQL 語句變成這樣：

SELECT * FROM users WHERE username = 'peter' OR '1' = '1'

這樣，他就能在不需要密碼的情況下導出你的整個用戶表的數據了。

那麼，我們如何防止這類事故的發生呢？主流的解決方法有兩種。轉義用戶輸入的數據或者使用封裝好的語句。轉義的方法是封裝好一個函數，用來對用戶提交的數據進行過濾，去掉有害的標籤。但是，我不太推薦使用這個方法，因爲比較容易忘記在每個地方都做此處理。

下面，我來介紹如何使用 PDO 執行封裝好的語句（ mysqi 也一樣）：

$username = $_GET['username'];
$query = $pdo->prepare('SELECT * FROM users WHERE username = :username');
$query->execute(['username' => $username]);
$data = $query->fetch();

動態數據的每個部分都以：做前綴。然後將所有參數作爲數組傳遞給執行函數，看起來就像 PDO 爲你轉義了有害數據一樣。

幾乎所有的數據庫驅動程序都支持封裝好的語句，沒有理由不使用它們！養成使用他們的習慣，以後就不會忘記了。

你也可以參考 phpdelusions 中的一篇關於動態構建 SQL 查詢時處理安全問題的文章。鏈接： https://phpdelusions.net/pdo/... 。

2. XSS

XSS 又叫 CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往 Web 頁面裏插入惡意 html 代碼，當用戶瀏覽該頁之時，嵌入其中 Web 裏面的 html 代碼會被執行，從而達到惡意攻擊用戶的特殊目的。

下面以一個搜索頁面爲例子：

<body>
<?php
$searchQuery = $_GET['q'];
/* some search magic here */
?>
<h1>You searched for: <?php echo $searchQuery; ?></h1>
<p>We found: Absolutely nothing because this is a demo</p>
</body>

因爲我們把用戶的內容直接打印出來，不經過任何過濾，非法用戶可以拼接 URL：

search.php?q=%3Cscript%3Ealert(1)%3B%3C%2Fscript%3E

PHP 渲染出來的內容如下，可以看到 Javascript 代碼會被直接執行：

<body>
<h1>You searched for: <script>alert(1);</script></h1>
<p>We found: Absolutely nothing because this is a demo</p>
</body>

問：JS 代碼被執行有什麼大不了的?

Javascript 可以:

偷走你用戶瀏覽器裏的 Cookie；
通過瀏覽器的記住密碼功能獲取到你的站點登錄賬號和密碼；
盜取用戶的機密信息；
你的用戶在站點上能做到的事情，有了 JS 權限執行權限就都能做，也就是說 A 用戶可以模擬成爲任何用戶；
在你的網頁中嵌入惡意代碼；
...

問：如何防範此問題呢?

好消息是比較先進的瀏覽器現在已經具備了一些基礎的 XSS 防範功能，不過請不要依賴與此。

正確的做法是堅決不要相信用戶的任何輸入，並過濾掉輸入中的所有特殊字符。這樣就能消滅絕大部分的 XSS 攻擊：

<?php

$searchQuery = htmlentities($searchQuery, ENT_QUOTES);

或者你可以使用模板引擎 Twig ，一般的模板引擎都會默認爲輸出加上 htmlentities 防範。

如果你保持了用戶的輸入內容，在輸出時也要特別注意，在以下的例子中，我們允許用戶填寫自己的博客鏈接：

<body>
  <a href="<?php echo $homepageUrl; ?>">Visit Users homepage</a>
</body>

以上代碼可能第一眼看不出來有問題，但是假設用戶填入以下內容：

#" onclick="alert(1)

會被渲染爲：

<body>
  <a href="#" onclick="alert(1)">Visit Users homepage</a>
</body>

永遠永遠不要相信用戶輸入的數據，或者，永遠都假設用戶的內容是有攻擊性的，態度端正了，然後小心地處理好每一次的用戶輸入和輸出。

另一個控制 XSS 攻擊的方法是提供一個 CSP Meta 標籤，或者標頭信息，更多詳情請見： https://www.html5rocks.com/en...

另外種 Cookie 時，如果無需 JS 讀取的話，請必須設置爲 "HTTP ONLY"。這個設置可以令 JavaScript 無法讀取 PHP 端種的 Cookie。

3. XSRF/CSRF

CSRF 是跨站請求僞造的縮寫，它是攻擊者通過一些技術手段欺騙用戶去訪問曾經認證過的網站並運行一些操作。

雖然此處展示的例子是 GET 請求，但只是相較於 POST 更容易理解，並非防護手段，兩者都不是私密的 Cookies 或者多步表單。

假如你有一個允許用戶刪除賬戶的頁面，如下所示：

<?php
//delete-account.php

$confirm = $_GET['confirm'];

if($confirm === 'yes') {
  //goodbye
}

攻擊者可以在他的站點上構建一個觸發這個 URL 的表單（同樣適用於 POST 的表單），或者將 URL 加載爲圖片誘惑用戶點擊：

<img src="https://example.com/delete-account.php?confirm=yes" />

用戶一旦觸發，就會執行刪除賬戶的指令，眨眼你的賬戶就消失了。

防禦這樣的攻擊比防禦 XSS 與 SQL 注入更復雜一些。

最常用的防禦方法是生成一個 CSRF 令牌加密安全字符串，一般稱其爲 Token，並將 Token 存儲於 Cookie 或者 Session 中。

每次你在網頁構造表單時，將 Token 令牌放在表單中的隱藏字段，表單請求服務器以後會根據用戶的 Cookie 或者 Session 裏的 Token 令牌比對，校驗成功纔給予通過。

由於攻擊者無法知道 Token 令牌的內容（每個表單的 Token 令牌都是隨機的），因此無法冒充用戶。

<?php /* 你嵌入表單的頁面 */ ?>

<form action="/delete-account.php" method="post">
  <input type="hidden" name="csrf" value="<?php echo $_SESSION['csrf']; ?>">
  <input type="hidden" name="confirm" value="yes" />
  <input type="submit" value="Delete my account" />
</form>
## 

<?php
//delete-account.php

$confirm = $_POST['confirm'];
$csrf = $_POST['csrf'];
$knownGoodToken = $_SESSION['csrf'];

if($csrf !== $knownGoodToken) {
  die('Invalid request');
}

if($confirm === 'yes') {
  //goodbye
}

請注意，這是個非常簡單的示例，你可以加入更多的代碼。如果你使用的是像 Symfony 這樣的 PHP 框架，那麼自帶了 CSRF 令牌的功能。

你還可以查看關於 OWASP 更詳細的問題和更多防禦機制的文章： https://github.com/OWASP/CheatS....

4. LFI

LFI （本地文件包含）是一個用戶未經驗證從磁盤讀取文件的漏洞。

我經常遇到編程不規範的路由代碼示例，它們不驗證過濾用戶的輸入。我們用以下文件爲例，將它要渲染的模板文件用 GET 請求加載。

<body>
<?php
  $page = $_GET['page'];
  if(!$page) {
    $page = 'main.php';
  }
  include($page);
?>
</body>

由於 Include 可以加載任何文件，不僅僅是PHP，攻擊者可以將系統上的任何文件作爲包含目標傳遞。

index.php?page=../../etc/passwd

這將導致 /etc/passwd 文件被讀取並展示在瀏覽器上。

要防禦此類攻擊，你必須仔細考慮允許用戶輸入的類型，並刪除可能有害的字符，如輸入字符中的“.” “/” “”。

如果你真的想使用像這樣的路由系統（我不建議以任何方式），你可以自動附加 PHP 擴展，刪除任何非 [a-zA-Z0-9-_] 的字符，並指定從專用的模板文件夾中加載，以免被包含任何非模板文件。

我在不同的開發文檔中，多次看到造成此類漏洞的 PHP 代碼。從一開始就要有清晰的設計思路，允許所需要包含的文件類型，並刪除掉多餘的內容。你還可以構造要讀取文件的絕對路徑，並驗證文件是否存在來作爲保護，而不是任何位置都給予讀取。

5. 不充分的密碼哈希

大部分的 Web 應用需要保存用戶的認證信息。如果密碼哈希做的足夠好，在你的網站被攻破時，即可保護用戶的密碼不被非法讀取。

首先，最不應該做的事情，就是把用戶密碼明文儲存起來。大部分的用戶會在多個網站上使用同一個密碼，這是不可改變的事實。當你的網站被攻破，意味着用戶的其他網站的賬號也被攻破了。

其次，你不應該使用簡單的哈希算法，事實上所有沒有專門爲密碼哈希優化的算法都不應使用。哈希算法如 MD5 或者 SHA 設計初衷就是執行起來非常快。這不是你需要的，密碼哈希的終極目標就是讓黑客花費無窮盡的時間和精力都無法破解出來密碼。

另外一個比較重要的點是你應該爲密碼哈希加鹽（Salt），加鹽處理避免了兩個同樣的密碼會產生同樣哈希的問題。

以下使用 MD5 來做例子，所以請千萬不要使用 MD5 來哈希你的密碼， MD5 是不安全的。

假如我們的用戶 user1 和 user315 都有相同的密碼 ilovecats123，這個密碼雖然看起來是強密碼，有字母有數字，但是在數據庫裏，兩個用戶的密碼哈希數據將會是相同的：5e2b4d823db9d044ecd5e084b6d33ea5 。

如果一個如果黑客拿下了你的網站，獲取到了這些哈希數據，他將不需要去暴力破解用戶 user315 的密碼。我們要儘量讓他花大精力來破解你的密碼，所以我們對數據進行加鹽處理：

<?php
//warning: !!這是一個很不安全的密碼哈希例子，請不要使用!!

$password = 'cat123';
$salt = random_bytes(20);

$hash = md5($password . $salt);

最後在保存你的唯一密碼哈希數據時，請不要忘記連 $salt 也已經保存，否則你將無法驗證用戶。

在當下，最好的密碼哈希選項是 bcrypt，這是專門爲哈希密碼而設計的哈希算法，同時這套哈希算法裏還允許你配置一些參數來加大破解的難度。

新版的 PHP 中也自帶了安全的密碼哈希函數 password_hash ，此函數已經包含了加鹽處理。對應的密碼驗證函數爲 password_verify 用來檢測密碼是否正確。password_verify 還可有效防止時序攻擊.

以下是使用的例子：

<?php

//user signup
$password = $_POST['password'];
$hashedPassword = password_hash($password, PASSWORD_DEFAULT);

//login
$password = $_POST['password'];
$hash = '1234'; //load this value from your db

if(password_verify($password, $hash)) {
  echo 'Password is valid!';
} else {
  echo 'Invalid password.';
}

需要澄清的一點是：密碼哈希並不是密碼加密。哈希（Hash）是將目標文本轉換成具有相同長度的、不可逆的雜湊字符串（或叫做消息摘要），而加密（Encrypt）是將目標文本轉換成具有不同長度的、可逆的密文。顯然他們之間最大的區別是可逆性，在儲存密碼時，我們要的就是哈希這種不可逆的屬性。

6. 中間人攻擊

MITM （中間人）攻擊不是針對服務器直接攻擊，而是針對用戶進行，攻擊者作爲中間人欺騙服務器他是用戶，欺騙用戶他是服務器，從而來攔截用戶與網站的流量，並從中注入惡意內容或者讀取私密信息，通常發生在公共 WiFi 網絡中，也有可能發生在其他流量通過的地方，例如ISP運營商。

對此的唯一防禦是使用 HTTPS，使用 HTTPS 可以將你的連接加密，並且無法讀取或者篡改流量。你可以從 Let's Encrypt 獲取免費的 SSL 證書，或從其他供應商處購買，這裏不詳細介紹如何正確配置 WEB 服務器，因爲這與應用程序安全性無關，且在很大程度上取決於你的設置。

你還可以採取一些措施使 HTTPS 更安全，在 WEB 服務器配置加上 Strict-Transport-Security 標示頭，此頭部信息告訴瀏覽器，你的網站始終通過 HTTPS 訪問，如果未通過 HTTPS 將返回錯誤報告提示瀏覽器不應顯示該頁面。

然而，這裏有個明顯的問題，如果瀏覽器之前從未訪問過你的網站，則無法知道你使用此標示頭，這時候就需要用到 Hstspreload。

可以在此註冊你的網站: https://hstspreload.org/

你在此處提交的所有網站都將被標記爲僅 HTTPS，並硬編碼到 Google Chrome、FireFox、Opera、Safari、IE11 和 Edge 的源代碼中。

你還可以在 DNS 配置中添加 Certification Authority Authorization (CAA) record ，可以僅允許一個證書頒發機構（例如： Let's encrypt）發佈你的域名證書，這進一步提高了用戶的安全性。

7. 命令注入

這可能是服務器遇到的最嚴重的攻擊，命令注入的目標是欺騙服務器執行任意 Shell 命令

你如果使用 shell_exec 或是 exec 函數。讓我們做一個小例子，允許用戶簡單的從服務器 Ping 不同的主機。

<?php

$targetIp = $_GET['ip'];
$output = shell_exec("ping -c 5 $targetIp");

輸出將包括對目標主機 Ping 5次。除非採用 sh 命令執行 Shell 腳本，否則攻擊者可以執行想要的任何操作。

ping.php?ip=8.8.8.8;ls -l /etc

Shell 將執行 Ping 和由攻擊者拼接的第二個命令，這顯然是非常危險的。

感謝 PHP 提供了一個函數來轉義 Shell 參數。

escapeshellarg 轉義用戶的輸入並將其封裝成單引號。

<?php

$targetIp = escapeshellarg($_GET['ip']);
$output = shell_exec("ping -c 5 $targetIp");

現在你的命令應該是相當安全的，就個人而言，我仍然避免使用 PHP 調用外部命令，但這完全取決於你自己的喜好。

另外，我建議進一步驗證用戶輸入是否符合你期望的形式。

8. XXE

XXE （XML 外部實體）是一種應用程序使用配置不正確的 XML 解析器解析外部 XML 時，導致的本地文件包含攻擊，甚至可以遠程代碼執行。

XML 有一個鮮爲人知的特性，它允許文檔作者將遠程和本地文件作爲實體包含在其 XML 文件中。

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY passwd SYSTEM "file:///etc/passwd" >]>
   <foo>&passwd;</foo>

就像這樣， /etc/passwd 文件內容被轉儲到 XML 文件中。

如果你使用 libxml 可以調用 libxml_disable_entity_loader 來保護自己免受此類攻擊。使用前請仔細檢查 XML 庫的默認配置，以確保配置成功。

9. 在生產環境中不正確的錯誤報告暴露敏感數據

[](https://secure.php.net/manual...，可能會在生產環境中因爲不正確的錯誤報告泄露了敏感信息，例如：文件夾結構、數據庫結構、連接信息與用戶信息。

你是不希望用戶看到這個的吧？

一般根據你使用的框架或者 CMS ，配置方法會有不同的變化。通常框架具有允許你將站點更改爲某種生產環境的設置。這樣會將所有用戶可見的錯誤消息重定向到日誌文件中，並向用戶顯示非描述性的 500 錯誤，同時允許你根據錯誤代碼檢查。

但是你應該根據你的 PHP 環境設置： error_reporting 與 display_errors.

10. 登錄限制

像登錄這樣的敏感表單應該有一個嚴格的速率限制，以防止暴力攻擊。保存每個用戶在過去幾分鐘內失敗的登錄嘗試次數，如果該速率超過你定義的閾值，則拒絕進一步登錄嘗試，直到冷卻期結束。還可通過電子郵件通知用戶登錄失敗，以便他們知道自己的賬戶被成爲目標。

一些其他補充

不要信任從用戶傳遞給你的對象 ID ，始終驗證用戶對請求對象的訪問權限
服務器與使用的庫時刻保持最新
訂閱關注安全相關的博客，瞭解最新的解決方案
從不在日誌中保存用戶的密碼
不要將整個代碼庫存儲在 WEB 根目錄中
永遠不要在 WEB 根目錄創建 Git 存儲庫，除非你希望泄露整個代碼庫
始終假設用戶的輸入是不安全的
設置系統禁止可疑行爲的 IP 顯示，例如：工具對 URL 隨機掃描、爬蟲
不要過分信任第三方代碼是安全的
不要用 Composer 直接從 Github 獲取代碼
如果不希望站點被第三方跨域 iframe，請設置反 iframe 標示頭
含糊是不安全的
如果你是缺乏實踐經驗的運營商或合作開發人員，請確保儘可能時常檢查代碼
當你不瞭解安全功能應該如何工作，或者爲什麼會安裝，請詢問知道的人，不要忽視它
永遠不要自己寫加密方式，這可能是個壞的方法
如果你沒有足夠的熵，請正確播種你的僞隨機數生成並捨棄
如果在互聯網上不安全，並有可能被竊取信息，請爲這種情況做好準備並制定事件響應計劃
禁用 WEB 根目錄列表顯示，很多 WEB 服務器配置默認都會列出目錄內容，這可能導致數據泄露
客戶端驗證是不夠的，需要再次驗證 PHP 中的所有內容
不惜一切代價避免反序列化用戶內容，這可能導致遠程代碼執行，有關此問題的詳細信息，請參閱此文章： https://paragonie.com/blog/20...

小貼士

我不是一個安全專家，恐無法做到事無鉅細。儘管編寫安全軟件是一個非常痛苦的過程，但還是可以通過遵循一些基本規則，編寫合理安全的應用程序。其實，很多框架在這方面也幫我們做了很多工作。

在問題發生之前，安全性問題並不像語法錯誤等可以在開發階段追蹤到。因此，在編寫代碼的過程中，應該時刻有規避安全風險的意識。如果你迫於業務需求的壓力而不得不暫時忽略一些安全防範的工作，我想你有必要事先告知大家這樣做的潛在風險。

如果你從這篇文章有所收益，也請把它分享給你的朋友們把，讓我們共建安全網站。

文章轉自：https://learnku.com/php/t/24930

更多文章：https://learnku.com/laravel/c...

PHP 安全問題入門：10 個常見安全問題 + 實例講解

1. SQL 注入

2. XSS

3. XSRF/CSRF

4. LFI

5. 不充分的密碼哈希

6. 中間人攻擊

7. 命令注入

8. XXE

9. 在生產環境中不正確的錯誤報告暴露敏感數據

10. 登錄限制

一些其他補充

小貼士

SQL優化-20231016

讓 Laravel Scout 導入提速 64 倍

你是如何處理 PHP 代碼中的枚舉類型 Enum 的？

解讀 Laravel 中的擴展自動註冊機制（Package Auto-discovery）

[擴展推薦] Laravel Tenancy —— 多站點架構方案

Laravel 服務容器必知必會

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結