溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
PHP常見的安全問題有哪些？針對這個問題，今天小編總結這篇有關php安全問題的文章，希望能幫助更多想解決這個問題的朋友找到更加簡單易行的辦法。 相對于其他幾種語言來說， 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 為你轉義了有害數據一樣。
幾乎所有的數據庫驅動程序都支持封裝好的語句，沒有理由不使用它們！養成使用他們的習慣，以后就不會忘記了。
2. XSS
XSS 又叫 CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往 Web 頁面里插入惡意 html 代碼，當用戶瀏覽該頁之時，嵌入其中 Web 里面的 html 代碼會被執行，從而達到惡意攻擊用戶的特殊目的。
下面以一個搜索頁面為例子：
<body> <?php $searchQuery = $_GET['q']; /* some search magic here */ ?> <h2>You searched for: <?php echo $searchQuery; ?></h2> <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> <h2>You searched for: <script>alert(1);</script></h2> <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>
永遠永遠不要相信用戶輸入的數據，或者，永遠都假設用戶的內容是有攻擊性的，態度端正了，然后小心地處理好每一次的用戶輸入和輸出。
另外設置 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. 在生產環境中不正確的錯誤報告暴露敏感數據
如果你不小心，可能會在生產環境中因為不正確的錯誤報告泄露了敏感信息，例如：文件夾結構、數據庫結構、連接信息與用戶信息。
你是不希望用戶看到這個的吧？
一般根據你使用的框架或者 CMS ，配置方法會有不同的變化。通常框架具有允許你將站點更改為某種生產環境的設置。這樣會將所有用戶可見的錯誤消息重定向到日志文件中，并向用戶顯示非描述性的 500 錯誤，同時允許你根據錯誤代碼檢查。
但是你應該根據你的 PHP 環境設置： error_reporting 與 display_errors.
10. 登錄限制
像登錄這樣的敏感表單應該有一個嚴格的速率限制，以防止暴力攻擊。保存每個用戶在過去幾分鐘內失敗的登錄嘗試次數，如果該速率超過你定義的閾值，則拒絕進一步登錄嘗試，直到冷卻期結束。還可通過電子郵件通知用戶登錄失敗，以便他們知道自己的賬戶被成為目標。
一些其他補充
不要信任從用戶傳遞給你的對象 ID ，始終驗證用戶對請求對象的訪問權限
服務器與使用的庫時刻保持最新
訂閱關注安全相關的博客，了解最新的解決方案
從不在日志中保存用戶的密碼
不要將整個代碼庫存儲在 WEB 根目錄中
永遠不要在 WEB 根目錄創建 Git 存儲庫，除非你希望泄露整個代碼庫
始終假設用戶的輸入是不安全的
設置系統禁止可疑行為的 IP 顯示，例如：工具對 URL 隨機掃描、爬蟲
不要過分信任第三方代碼是安全的
不要用 Composer 直接從 Github 獲取代碼
如果不希望站點被第三方跨域 iframe，請設置反 iframe 標示頭
含糊是不安全的
如果你是缺乏實踐經驗的運營商或合作開發人員，請確保盡可能時常檢查代碼
當你不了解安全功能應該如何工作，或者為什么會安裝，請詢問知道的人，不要忽視它
永遠不要自己寫加密方式，這可能是個壞的方法
如果你沒有足夠的熵，請正確播種你的偽隨機數生成并舍棄
如果在互聯網上不安全，并有可能被竊取信息，請為這種情況做好準備并制定事件響應計劃
禁用 WEB 根目錄列表顯示，很多 WEB 服務器配置默認都會列出目錄內容，這可能導致數據泄露
客戶端驗證是不夠的，需要再次驗證 PHP 中的所有內容
小貼士
我不是一個安全專家，恐無法做到事無巨細。盡管編寫安全軟件是一個非常痛苦的過程，但還是可以通過遵循一些基本規則，編寫合理安全的應用程序。其實，很多框架在這方面也幫我們做了很多工作。
在問題發生之前，安全性問題并不像語法錯誤等可以在開發階段追蹤到。因此，在編寫代碼的過程中，應該時刻有規避安全風險的意識。如果你迫于業務需求的壓力而不得不暫時忽略一些安全防范的工作，我想你有必要事先告知大家這樣做的潛在風險。
如果你從這篇文章有所收益，也請把它分享給你的朋友們把，讓我們共建安全網站。
關于php安全問題就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
