一個通過使用UNHEX繞過SQL注入的問題

在平時的開發過程中，關於代碼中存在SQL注入的問題，想必大家都有所認識和瞭解，也都知道通用的解決方案。

但最近看到另外一種防止SQL注入的方式是這樣的：

$sql = sprintf("SELECT * FROM `test1` WHERE `name` = unhex('%s')", bin2hex($name));

即先使用PHP內建的函數bin2hex函數將輸入待查詢字串處理成16進位字串，然後再SQL執行過程中使用資料庫本身的unhex函數將該16進位字串反轉為原先的正常字串。

這樣即便$name的值為'maratrix' or 1 = 1也會正常被當作查詢字串處理，而不存在SQL注入的問題了。

查了下相關資料，也沒有弄明白這其中能夠繞過SQL注入的原理，希望大家協助解釋下其中的原因。

謝謝~

回複內容：

在平時的開發過程中，關於代碼中存在SQL注入的問題，想必大家都有所認識和瞭解，也都知道通用的解決方案。

但最近看到另外一種防止SQL注入的方式是這樣的：

$sql = sprintf("SELECT * FROM `test1` WHERE `name` = unhex('%s')", bin2hex($name));

即先使用PHP內建的函數bin2hex函數將輸入待查詢字串處理成16進位字串，然後再SQL執行過程中使用資料庫本身的unhex函數將該16進位字串反轉為原先的正常字串。

這樣即便$name的值為'maratrix' or 1 = 1也會正常被當作查詢字串處理，而不存在SQL注入的問題了。

查了下相關資料，也沒有弄明白這其中能夠繞過SQL注入的原理，希望大家協助解釋下其中的原因。

謝謝~

bin2hex之後$name就全部轉換成hex格式的資料了，在拼接到sql裡面之後就不會產生存在漏洞的語句了。最好還是建議你讓$name的值為maratrix' or 1 = 1，然後把$sql的值echo一下就明白了。

因為unhex是mysql函數，在mysql裡面執行自然就沒問題了。
SELECT * FROM test1 WHERE name = unhex('6d6172617472697827206f722031203d2031');
name無論啥值，都不會拆分sql了。

