目錄

• 為什麼要聊 SQL 注入攻擊？
• 什麼是 SQL 注入攻擊？
• 如何進行 SQL 注入攻擊？
• 如何防範？
• 常見面試題
• 瞎比比

為什麼要聊 SQL 注入攻擊？

我這人有個想法，就是不管自己跳不跳槽，每年都會調個時間去面試一下，一來可以摸摸自己的底，知道自己的價值，二來也可以知道市場的環境局勢。可以更好地為自己定位，能及時查缺補漏。所以半年前我也執行了這個想法，去參加了面試。我當時就被問到了 SQL 注入攻擊，你說不知道 SQL 注入吧，我又聽說過，但你叫我說清楚吧，我又說不清楚，於是場面一度很尷尬。也是後面結束面試之後，查資料才搞清楚的。那麼今天我們就來聊聊 SQL 注入攻擊。

什麼是 SQL 注入攻擊？

首先我們得知道什麼是 SQL 注入攻擊，官方一點的說法是這樣的：

所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。

那通俗一點呢？這麼來說吧，一般我們提交的表單數據（未經過濾的情況下）都會拼接到 SQL 查詢語句中的，就例如：

SELECT * FROM users WHERE name='zone'

其中 name 參數 zone 就是從表單中傳過來的數據，如果傳的參數不是 zone，而是一條 SQL 語句，那麼就可能騙過了 SQL 數據庫，從而執行了一段惡意的代碼。達到了我們（程序員）意料之外的結果。

如何進行 SQL 注入攻擊？

說了那麼多，那究竟是怎麼進行攻擊的呢？我自己能夠攻擊一下自己，測試一下嗎？別急，現在就來試試看。

普通查詢 - 圖1

惡意查詢 - 圖2

普通查詢中，我們傳入的查詢數據為 1，惡意查詢中，我們傳入的數據為：

圖 2 參數：-1 OR 1=1

這各個語句中 id=-1 一般為 False，而 1=1 卻恆為 true，所以這個查詢語句能查詢到所有結果，這是與我們編程的初衷相違背的。

普通查詢 - 圖3

惡意查詢 - 圖4

惡意查詢 - 圖5

一般我們用戶登錄都需要用戶名和密碼，如圖 3，需要用戶名：zone 和密碼：123 方可查詢相關信息。但如圖 4、圖 5，我的用戶名參數為如下：

圖 4 參數：zone'#
圖 5 參數（--後面有一空格）：zone'-- 

這兩個參數，在我輸入的密碼不正確的情況下，也查詢出了結果，是因為 SQL 語句中有兩種註釋，一種是： # ，另一種是：-- ，這兩條查詢語句正式利用了這個，導致 SQL 認為後面的語句是註釋。從而，不管你輸入的密碼是否正確，都可以登錄。這個也違背了我們編程的初衷。

當然，SQL 注入攻擊不止這些，我這裡只是列舉了其中的一些操作，這些操作簡單，你也可以自行測試。更多的注入方式，可以自行到網絡上搜索，也可以看看這篇文章：

https://www.jianshu.com/p/078df7a35671

如何防範？

防範 SQL 注入攻擊，我在網絡上搜尋了一些方法，僅供參考建議。

• 把應用服務器的數據庫權限降至最低，儘可能地減少 SQL 注入攻擊帶來的危害
• 避免網站打印出SQL錯誤信息，比如類型錯誤、字段不匹配等，把代碼裡的SQL語句暴露出來，以防止攻擊者利用這些錯誤信息進行SQL注入。
• 對進入數據庫的特殊字符（'"\尖括號&*;等）進行轉義處理，或編碼轉換。
• 所有的查詢語句建議使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到SQL語句中，即不要直接拼接SQL語句。
• 在測試階段，建議使用專門的 SQL 注入檢測工具進行檢測。網上有很多這方面的開源工具，例如sqlmap、SQLninja等。
• 善用數據庫操作庫，有些庫包可能已經做好了相關的防護，我們只需閱讀其文檔，看是否支持相應的功能即可。

常見面試題

• 說說什麼是 SQL 注入？
• 說說 SQL 注入的危害？
• 舉個 SQL 注入的栗子？
• 如何猜測、確認數據庫表名？

這些問題基本在本文中都能找到答案，我也就不一一再寫一般了。

瞎比比

ok，關於 SQL 注入攻擊就說到這裡吧，這個也是面試官經常會問到問題。如果你還不會，建議儘快掌握。如果哪天面試官問到你，有用到了我文章中的知識，要回來報喜呀！

閱讀更多 小白學Python 的文章

關鍵字: 跳槽那些事兒 SQL 自己