SQL 語句文本對于數(shù)據(jù)庫來說，是一種指令，與 Shell 中輸入的一條條命令行很類似。我們在 SQL 中混入的各種值就是操作的參數(shù)。

考慮一個 WHERE user_id = 10 的篩選，WHERE 的條件包含兩個部分：按用戶篩選，以及用戶 id 的值，后者即為篩選操作的參數(shù)。

當用戶 id 直接混在 SQL 中，表示 id 值的文本作為 SQL 正文的一部分，就很容易被動手腳，攻擊者只要偽造一個令你最終也能符合語法的 偽裝值就行。

比如 WHERE user_id = 10;delete from xxxx

這樣，工程師直接拼到里面之后，在執(zhí)行引擎里，它分析我們的語句，發(fā)現(xiàn)是兩個子句。就會執(zhí)行后面的注入的 SQL。

上述過程的問題在于，執(zhí)行引擎理解到的 SQL 語義與我們要表達的不一致。我們隱含地意思是，在 WHERE user_id = 之后的值都被當作 user_id 的篩選條件，而不應該有其他語句出現(xiàn)。但是，基于 SQL 分析來執(zhí)行數(shù)據(jù)交互，這種誤解是無法解除的，比如，上面的例子，偽裝之后，它也是個符合語法的 SQL。

參數(shù)化為我們提供了消除這種誤解的能力。在遇到參數(shù)時，不管輸入任何值，都將整個值作為參數(shù)的值，而不是原始 SQL 文本的一部分。

在上面的例子里，如果使用參數(shù)化 SQL，則 10;delete from xxxx 整體會作為用于比對的 user_id 值，顯然找不到。而且數(shù)據(jù)庫不會被注入，因為這時 delete from xxxx 是參與運算的值的一部分，而不是 SQL 操作指令的一部分。

其他答案里有提到，這是一種抽象。如果做過表達式解析的練習，你會發(fā)現(xiàn)，操作數(shù)與操作算子是兩種不同性質(zhì)的東西。

SQL 注入的原理就是，如果簡單地通過拼接字符串來獲得 SQL 文本，就會使本應屬于操作數(shù)的內(nèi)容被當作操作算子來執(zhí)行了。

總結(jié)

以上是生活随笔為你收集整理的mysql参数化查询为什么可以实现_为什么参数化SQL查询可以防止SQL注入?的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。