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 */
?>
<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>
永遠永遠不要相信用戶輸入的數據，或者，永遠都假設用戶的內容是有攻擊性的，態度端正了，然后小心地處理好每一次的用戶輸入和輸出。
另外設置 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 令牌的功能。
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）是將目標文本轉換成具有不同長度的、可逆的密文。顯然他們之間最大的區別是可逆性，在儲存密碼時，我們要的就是哈希這種不可逆的屬性。
