這一篇我們討論一下僞命題SQL注入
首先簡單介紹SQL注入的原理，當我們從用戶界面採集文本框輸入內容傳到服務端，並用此內容於查詢數據庫的時候，在不考慮安全的情況下可能會有人使用sql語句拼接，而如果輸入的是特殊的字符串，sql語句的原意就會被篡改。
打比方，獲取採集數據文本 account 和password，然後拼接 sql = "select * from user where account = '" + account + "' and password='" + password + "';";
這樣的查詢語句應該不難理解，然後我們在password中填寫1' or 1=1 '
這樣sql語句就被拼接爲“select * from user where account = 'xxx' and password = '1' or 1=1 '';”
於是乎。。。。在完全不知道密碼的情況下，登陸成功。
但是這種例子是個超級僞命題，因爲通常賬號密碼的驗證都是sql查賬號然後比對密碼，而且密碼通常經過加密。所以這個例子只是爲了讓大家理解sql注入的原理。
現在我們來看個稍微正常的例子：
這是一個查詢電影的例子，我們在輸入行中打入“123' UNION SELECT 1,2,3,DATABASE(),VERSION(),4,5'”，於是乎，數據庫的信息就被獲取到了
然後我們可以通過特殊的查詢語句，依次獲取當前數據庫所含的表，每張表的數據等各種信息。
到這一步爲止，能做到竊取多少數據就看攻擊者的數據庫基礎啦。
然而問題在於，sql注入真的就是個僞命題，因爲，現階段基本上正常網站都是完全沒法用sql注入攻擊的，這一點與前幾章的攻擊手段形成鮮明對比。。
我們都知道，如java的preparedstatement、php的pdo等等都支持佔位符功能，佔位符不僅可以用於綁定blob類型的數據，而且可以防禦sql注入，而且是絕對防禦。
那麼問題來了，爲什麼這玩意可以防範呢？查詢網上資料，大多數人都說是把單引號變成"\'"，的確在正常情況下這種方式的確可以有效防範sql注入，但是人類還是非常機智的，很快就有人發現0xbf27 字符可以有效破解這種轉義。然而依舊沒法破解佔位符綁定。換句話說，這已經非常明顯地表明，佔位符綁定並不是網上大多數博客所說的特殊字符轉義那麼簡單了。
那麼問題來了，究竟是怎麼做到的呢，首先我們要考慮一件事情，佔位符的功能究竟是數據庫本身完成的還是開發語言來完成的。假設是數據庫本身完成的，也就是說數據庫底層完成了佔位符綁定，那麼這其中原理就不是開發語言的範疇，也就是說本身就是數據庫對應的一種機制，也就不需要考慮其原理。反之如果是開發語言完成的，我們就有必要去了解底層究竟如何和數據庫進行交互的。
答案是前者，這表明我們可能並沒有辦法知道數據庫是怎麼實現這一功能的：
SET @sql = "update t_admin set c_name = ? WHERE c_name = ?";
SET @param1 = 'admin';
SET @param2 = 'admin1';
PREPARE stmt FROM @sql;
EXECUTE stmt USING @param1, @param2;
DEALLOCATE PREPARE stmt;
很簡單的例子，來說明數據庫sql語句如何綁定數據。並不是網上所說的字符轉義。
完畢！！！