10 個 PHP 常見安全性問題（實例講解）

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

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

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

1. SQL 注入

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

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

攻擊者控制透過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/sql_injection_example
2. XSS
#XSS 又叫CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者在 Web 頁面插入惡意 html 程式碼，當使用者瀏覽該頁之時，嵌入其中 Web 裡面的 html 程式碼會被執行，從而達到惡意攻擊使用者的特殊目的。 
下面以一個搜尋頁面為例子：


You searched for: 
We found: Absolutely nothing because this is a demo
因為我們把使用者的內容直接列印出來，不經過任何過濾，非法使用者可以拼接URL：
search.php?q=%3Cscript%3Ealert(1)%3B%3C%2Fscript%3E
PHP渲染出來的內容如下，可以看到Javascript 程式碼會直接執行：

You searched for: 
We found: Absolutely nothing because this is a demo
問：JS 程式碼被執行有什麼大不了的？ 
Javascript 可以:
● 偷走你使用者瀏覽器裡的Cookie;
● 透過瀏覽器的記住密碼功能取得到你的網站登錄帳號與密碼；
● 竊取使用者的機密資料；
● 你的使用者在網站上能做到的事情，有了JS 權限執行權限就都能做，也就是說A 使用者可以模擬成為任何使用者；
● 在你的網頁中嵌入惡意程式碼；
...
問：如何防範此問題呢？ 
好消息是比較先進的瀏覽器現在已經具備了一些基礎的 XSS 防範功能，不過請不要依賴與此。 
正確的做法是堅決不要相信使用者的任何輸入，並過濾掉輸入中的所有特殊字元。這樣就能消滅絕大部分的 XSS 攻擊：
或是你可以使用模板引擎 Twig ，一般的模板引擎都會預設為輸出加上 htmlentities 防範。 
如果你保持了使用者的輸入內容，在輸出時也要特別注意，在以下的例子中，我們允許使用者填寫自己的部落格連結：

  Visit Users homepage
以上程式碼可能第一眼看不出來有問題，但是假設用戶填入以下內容：
#" onclick="alert(1)
會被渲染為：

  Visit Users homepage
永遠永遠不要相信用戶輸入的數據，或者，永遠都假設用戶的內容是有攻擊性的，態度端正了，然後小心地處理好每一次的使用者輸入和輸出。 
另一個控制XSS 攻擊的方法是提供一個CSP Meta 標籤，或標頭信息，更多詳情請見：
https://phpdelusions.net/pdo/ sql_injection_example
另外设置 Cookie 时，如果无需 JS 读取的话，请必须设置为 "HTTP ONLY"。这个设置可以令 JavaScript 无法读取 PHP 端种的 Cookie。
3. XSRF/CSRF
CSRF 是跨站请求伪造的缩写，它是攻击者通过一些技术手段欺骗用户去访问曾经认证过的网站并运行一些操作。
虽然此处展示的例子是 GET 请求，但只是相较于 POST 更容易理解，并非防护手段，两者都不是私密的 Cookies 或者多步表单。
假如你有一个允许用户删除账户的页面，如下所示：
攻击者可以在他的站点上构建一个触发这个 URL 的表单（同样适用于 POST 的表单），或者将 URL 加载为图片诱惑用户点击：
用户一旦触发，就会执行删除账户的指令，眨眼你的账户就消失了。
防御这样的攻击比防御 XSS 与 SQL 注入更复杂一些。
最常用的防御方法是生成一个 CSRF 令牌加密安全字符串，一般称其为 Token，并将 Token 存储于 Cookie 或者 Session 中。
每次你在网页构造表单时，将 Token 令牌放在表单中的隐藏字段，表单请求服务器以后会根据用户的 Cookie 或者 Session 里的 Token 令牌比对，校验成功才给予通过。
由于攻击者无法知道 Token 令牌的内容（每个表单的 Token 令牌都是随机的），因此无法冒充用户。


  
  
  

## 
请注意，这是个非常简单的示例，你可以加入更多的代码。如果你使用的是像 Symfony 这样的 PHP 框架，那么自带了 CSRF 令牌的功能。
你还可以查看关于 OWASP 更详细的问题和更多防御机制的文章： 
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md
4. LFI
LFI （本地文件包含） 是一个用户未经验证从磁盘读取文件的漏洞。
我经常遇到编程不规范的路由代码示例，它们不验证过滤用户的输入。我们用以下文件为例，将它要渲染的模板文件用 GET 请求加载。


由于 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 的密码。我们要尽量让他花大精力来破解你的密码，所以我们对数据进行加盐处理：
最后在保存你的唯一密码哈希数据时，请不要忘记连 $salt 也已经保存，否则你将无法验证用户。
在当下，最好的密码哈希选项是 bcrypt，这是专门为哈希密码而设计的哈希算法，同时这套哈希算法里还允许你配置一些参数来加大破解的难度。
新版的 PHP 中也自带了安全的密码哈希函数 password_hash ，此函数已经包含了加盐处理。对应的密码验证函数为 password_verify 用来检测密码是否正确。password_verify 还可有效防止 时序攻击.
以下是使用的例子：
需要澄清的一点是：密码哈希并不是密码加密。哈希（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 不同的主机。
输出将包括对目标主机 Ping 5 次。除非采用 sh 命令执行 Shell 脚本，否则攻击者可以执行想要的任何操作。
ping.php?ip=8.8.8.8;ls -l /etc
Shell 将执行 Ping 和由攻击者拼接的第二个命令，这显然是非常危险的。
感谢 PHP 提供了一个函数来转义 Shell 参数。
escapeshellarg 转义用户的输入并将其封装成单引号。
现在你的命令应该是相当安全的，就个人而言，我仍然避免使用 PHP 调用外部命令，但这完全取决于你自己的喜好。
另外，我建议进一步验证用户输入是否符合你期望的形式。
8. XXE
XXE （XML 外部实体） 是一种应用程序使用配置不正确的 XML 解析器解析外部 XML 时，导致的本地文件包含攻击，甚至可以远程代码执行。
XML 有一个鲜为人知的特性，它允许文档作者将远程和本地文件作为实体包含在其 XML 文件中。

 
   ]>
   &passwd;
就像这样， /etc/passwd 文件内容被转储到 XML 文件中。
如果你使用 libxml 可以调用 libxml_disable_entity_loader 来保护自己免受此类攻击。使用前请仔细检查 XML 库的默认配置，以确保配置成功。
9. 在生产环境中不正确的错误报告暴露敏感数据
如果你不小心，可能会在生产环境中因为不正确的错误报告泄露了敏感信息，例如：文件夹结构、数据库结构、连接信息与用户信息。
你是不希望用户看到这个的吧？
一般會根據你使用的框架或 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/2016/04/securely-implementing-de-serialization-in -php
小秘訣
我不是安全專家，恐無法做到事無鉅細。儘管編寫安全軟體是一個非常痛苦的過程，但還是可以透過遵循一些基本規則，編寫合理安全的應用程式。其實，很多框架在這方面也幫我們做了很多工作。 
在問題發生之前，安全性問題並不像語法錯誤等可以在開發階段追蹤。因此，在編寫程式碼的過程中，應該時時刻刻有規避安全風險的意識。如果你迫於業務需求的壓力而不得不暫時忽略一些安全防範的工作，我想你有必要事先告知大家這樣做的潛在風險。 
如果你從這篇文章有所收益，也請把它分享給你的朋友們把，讓我們共建安全網站。 
以上是10 個 PHP 常見安全性問題（實例講解）的詳細內容。更多資訊請關注PHP中文網其他相關文章！