如何從根本上防止 SQL 注入？
SQL注入導致的安全問題數不勝數，為什麼這麼多年來同樣的問題一再發生？
如果是因為SQL腳本拼接的原因，為什麼不在新的實現中採用api調用的方式來杜絕漏洞？
可能是問題描述不夠清晰，再補充一些吧。
樓主本人是懂得如何防止，而且參數化查詢這樣的方法本身也是很容易掌握的。
自己的疑問是，面對一個很容易解決，又有巨大危害的安全漏洞，靠用戶（開發者也是用戶）的自覺去避免，這樣的機制是不是很不合理？
各大資料庫廠商在自己的實現上面有沒有在這方面的做出一些努力？
如果說參數化查詢就可以解決SQL注入，那麼新的SQL標準里為什麼不使用參數化查詢作為查詢語句默認實現？是因為這樣的實現會降低性能，還是說SQL語言本身的特性不容易去實現？或者是標準的制定者認為這個問題已經可以靠使用者自身的自我規範來避免，所以沒有必要去改進？
根本上杜絕的方案太多太簡單了，SQL注入這種攻擊手段說白了和直接把門踹開偷東西一樣Low，這麼多年一爆再爆我也很震精。不過想想其實都是一群小白拿著幾十年前的小白寫的東西改改用才會這樣的。
有人非說我沒回答問題，OK，根本的手段就是參數化查詢或者做詞法分析。
@pansz 的答案的確是說到了一個關鍵，也就是如果支持文本式的指令，那這事兒是沒有辦法杜絕的，只能在外面套上一個殼，也就是詞法分析。
但是現代資料庫卻不是只提供了SQL文本查詢，參數化查詢也是標準API之一，當然還有存儲過程，這些高級的API都可以有效的杜絕SQL注入這種問題。在MySQL都支持存儲過程的今天，還有這麼多注入漏洞實在是讓人費解。
不使用支持SQL的資料庫過於偏頗了，幾乎所有的關係型資料庫都支持SQL查詢，但也提供了安全的查詢方式。SQL注入並不是一個在SQL內不可解決的問題，這種攻擊方式的存在也不能完全歸咎於SQL這種語言，因為注入的問題而放棄SQL這種方式也是因噎廢食。首先先說一個我在其他回答中也曾提到過的觀點：沒有（運行時）編譯，就沒有注入。
SQL注入產生的原因，和棧溢出、XSS等很多其他的攻擊方法類似，就是未經檢查或者未經充分檢查的用戶輸入數據，意外變成了代碼被執行。針對於SQL注入，則是用戶提交的數據，被資料庫系統編譯而產生了開發者預期之外的動作。也就是，SQL注入是用戶輸入的數據，在拼接SQL語句的過程中，超越了數據本身，成為了SQL語句查詢邏輯的一部分，然後這樣被拼接出來的SQL語句被資料庫執行，產生了開發者預期之外的動作。
所以從根本上防止上述類型攻擊的手段，還是避免數據變成代碼被執行，時刻分清代碼和數據的界限。而具體到SQL注入來說，被執行的惡意代碼是通過資料庫的SQL解釋引擎編譯得到的，所以只要避免用戶輸入的數據被資料庫系統編譯就可以了。
現在的資料庫系統都提供SQL語句的預編譯（prepare）和查詢參數綁定功能，在SQL語句中放置佔位符"?"，然後將帶有佔位符的SQL語句傳給資料庫編譯，執行的時候才將用戶輸入的數據作為執行的參數傳給用戶。這樣的操作不僅使得SQL語句在書寫的時候不再需要拼接，看起來也更直接，而且用戶輸入的數據也沒有機會被送到資料庫的SQL解釋器被編譯執行，也不會越權變成代碼。
至於為什麼這種參數化的查詢方式沒有作為默認的使用方式，我想除了兼容老系統以外，直接使用SQL確實方便並且也有確定的使用場合。
多說一點，從代碼的角度來看，拼接SQL語句的做法也是不恰當的。DELETE FROM planet WHERE name = "mercury";
DELETE FROM planet WHERE name = "venus";
DELETE FROM planet WHERE name = "earth";
DELETE FROM planet WHERE name = "mars";
我修改一下那個很經典的笑話：程序員不應該執行刪除地球這樣的SQL語句，而是寫刪除一個行星，然後將地球當作參數傳入。
$stmt = $mysqli-&>prepare("DELETE FROM planet WHERE name = ?");
$stmt-&>bind_param("s", "earth");
$stmt-&>execute();
更多閱讀：
MySQL :: MySQL 5.1 Reference Manual :: 13.5 SQL Syntax for Prepared Statements
Prepared statement
簡單，sql injection的原因就是用戶提交的參數可以入庫並且當做sql結構化查詢語句執行
根本辦法:杜絕用戶提交的參數入庫並且執行
具體做法:將查詢參數化或者詞法分析(一樓已說)但是如果不能做到的話，建議站庫分離(web伺服器和資料庫伺服器做隔離分開)waf什麼的都是扯球淡，只要心情好有時間都能繞，做cdn防護的雲waf更是扯淡，秒過(具體不好吐槽，怕做雲waf的大牛們噴我)
以上都是我編的，現在我編不下去了~
我給你說，大不了base64()一下再拼接，我放著讓他注，能注進算我輸
為什麼不用？
大部分人說效率
然而如今性能過剩的年代真的用不起？樓主並不是問如何防止SQL注入的。 而是問這麼頻繁而簡單的問題為什麼一再發生？資料庫廠商是不是應該做些什麼。
首先，這並不是一個複雜的問題。其次，在這一點上資料庫廠商能做的已經都做了。 @槐磊 已經說的很清楚了。出問題的是plain sql。plain sql意味著資料庫廠商給了程序員100%的權利。如果要從資料庫廠商方面100%杜絕。就只能是禁止了plain sql。但這不可能，因為plain sql的需求是確實存在的。就像linux不給你root許可權一樣。
所以真正的問題在程序員方面。以我的經驗，有兩種比較典型的情況，
第一種：程序員太菜，太懶，太忙。由於各種大意，或者壓根不知道這麼一回事而導致的。通常來說，這類情況多輸出現在初級程序員身上。但是也有資深的程序員犯這種低級錯誤。人都有具體的情況。每天的休息狀況，情緒，狀態都不同。只要是人就難免有出錯的時候。
第二種：程序架構複雜，人數多，設計不夠好就會出問題。比如數據從前端到資料庫經歷的代碼是3個人寫的。每個人都可以處理，但由於溝通，設計不利。每個人都認為別人會處理。就過導致誰都沒處理。
我能想到的經常發生的，就是這兩種了。希望大家再補充。
由此可見，這個問題實際上不是一個資料庫的問題了。而是一個軟體開發管理問題了。所以，從這一點上來說。是不可能100%杜絕的。就像你不能要求程序員的代碼100%沒bug一樣。那如何解決的。我能想到的最好的辦法就是：
1，給出清晰地架構設計，明確驗證數據的地方。2. 測試，測試，測試！！！
3. 對於項目經理來說，如果發生注入的情況了。要檢查發生的原因，根據具體情況，如果真是因為程序員出現了不應給的疏忽，並且經常出現的話。就真的要換人了。
SQL注入本質上是數據和語句的混淆。
在數據被拼入SQL模版變成SQL片段的時候，正是防止SQL注入漏洞產生的最佳時機，這時候什麼是數據什麼是語句分得最清楚，只要使用強類型轉化就可以避免數據和語句的混淆，而無需特徵匹配或語法分析。一但失去這個時機，紅豆和綠豆混在一起，再想摘出來就難了，難免會被繞過。
參數化只是捕捉這個時機並有效處理的最佳手段而已，這裡「最佳」是包含了有效性、成本、可控等若干方面的考量。看到很多人粗暴的將其理解為「參數化能防SQL注入」，然後舉各種反例，也挺無奈的。
相關討論中，很多人混淆了「抵禦SQL注入攻擊」和「防止SQL注入漏洞的產生」兩個概念，沒有做過企業級安全支持的人——無論他是其他領域多NB的專家，還是對安全一知半解的工程師——也很難真正理解後者的真實含義和必要性，而將其看作資料庫系統本身的弱點加以防禦，從而陷入特徵匹配的攻防糾纏中。
還有很多人混淆了「我如何防止SQL注入漏洞的產生」和「我如何避免公司里的工程師產生SQL注入漏洞」。刺客和軍官本身就是兩個職業，在高深的武藝、精良的裝備之外，還有很多諸如組織形式、流程、士氣、主要矛盾主要方面這樣的問題。作為一個公司級別的解決方案，如果在資料庫層面沒法保證讓程序員撒花的寫代碼也能避免SQL注入攻擊的話，那你就不得不去好好面對「我如何避免公司里的工程師產生SQL注入漏洞」的問題。工程師不可能都是安全方面的專家，你也不可能讓工程師寫代碼的時候始終崩著弦去考慮如何避免OWASP TOP 10這類問題，在這個前提下怎麼解決問題，似乎安全框架+編碼規範+白盒檢查成了最好的選擇。
SQL注入的危害性使得企業不得不追求徹底防禦，不能接受潛在的繞過風險。而徹底防禦又只能在生成SQL片段的時機實現，控制這個時機的是開發工程師而不是資料庫，因此這是個系統問題和管理問題，而不是技術問題，至少不是純粹的技術問題，特別不是SQL注入檢測技術的問題。
回到問題本身，SQL注入問題既不能「靠用戶（開發者也是用戶）的自覺去避免」，也不能完全脫離用戶（開發者也是用戶）而指望資料庫層面去避免。對於那些不了解SQL注入漏洞細節或不關心SQL注入漏洞或沒精力去關心SQL注入漏洞的工程師，你要給他們一條儘可能簡單可行透明的方案來避免SQL注入漏洞，告訴他這樣寫就可以了，這就是安全框架；然後告訴他或者讓他的老大告訴他你必須這樣寫，這就是安全編碼規範；然後你有手段在他沒有這樣寫的時候能夠檢查出來（這比檢查出漏洞要容易）並推動他改正，這就是白盒檢查。
我們現在的互聯網產品SQL注入漏洞仍然層出不窮，並不是這套思路有問題，相反恰恰是這套思路沒有完善。
一方面是框架方案本身不完善，以SQL注入漏洞為例，參數化是防SQL注入框架級方案的重要部分，但僅靠參數化沒法很好滿足開發過程中一些常見需求，如逗號分割的id列表問題、排序標記的問題等等（其實這些問題真要用參數化的方案解決也可以），使得開發更願意在這些地方使用非參數化或偽參數化的方法（比如拼接SQL片段後再把整個片段當作參數扔進去exec）。這些問題在參數化的基礎上，再加以改進，仍然守著拼接SQL片段時進行強類型轉換的思路，仍然是能很好解決的，也就是繼續完善參數化方案的問題，而不是看上去那樣「參數化解決不了問題」。
另一方面，安全編碼規範的制定、培訓、流程建設和實施保證上也做得遠遠不到位，開發leader們更希望後面的資料庫或者前面的安全防禦上能有手段去解決SQL注入問題，對於安全工程師來說，設置並維護幾個特徵串、語法分析場景也遠比做那些安全框架、編碼規範、白盒掃描來得要輕鬆實在，彼此在心照不宣中度過今天，自然不能指望明天能徹底踏實。1. 選擇不用SQL；
2. 使用ibatis等框架預設的寫法；
要想解決這個問題很簡單，但都不是在資料庫層面的，通過編程框架或者詞法分析的方法本質上是在 SQL 之上再增加了一個適配層，用戶的輸入先經過了某個適配層的處理然後才進入 SQL 語句。而參數化查詢看起來是繞開了 SQL，但不能阻止程序員非要使用 SQL 進行查詢。
而這些方法都違背了題主問題的本意。題主的本意不是問如何解決 SQL 注入問題，而是問能否從資料庫自身的層面解決 SQL 注入問題，但這個問題在 SQL 內不可能解決。
SQL 注入的本質在於它是一個語言而不是一個特定格式的API。所以你無法單獨的給它傳輸參數什麼的，只能整體的執行一條語句。只要用戶輸入的東西可以直接進入 SQL，一個元素就可以變成一條語句，那麼 SQL 注入就無法防止。
更明確一些，這個問題並不是 SQL 語言特有的，而是只要 API 是一個語言，這個問題就必然存在。除非這個資料庫的 API 並不以語言的方式提供，而是以某種不靈活不方便（但更安全）的方式。
我認為，要想完全從資料庫本身解決這個問題，唯一的方法只能是不用 SQL ，不使用支持 SQL 的資料庫，資料庫的 API 以某種並非文本語言的方式提供。——純粹資料庫的角度，只要用 SQL 語言發命令的這種方式仍然存在，你就沒法擋住手殘的程序員，除非完全禁止掉 SQL。多年前寫過一篇 「Web安全之SQL注入攻擊技巧與防範」，今天回頭再看依然有價值，就偷個懶，直接貼過來了。
Web安全簡史
在Web1.0時代，人們更多是關注伺服器端動態腳本語言的安全問題，比如將一個可執行腳本（俗稱Webshell）通過腳本語言的漏洞上傳到伺服器上，從而獲得伺服器許可權。在Web發展初期，隨著動態腳本語言的發展和普及，以及早期工程師對安全問題認知不足導致很多」安全血案」的發生，至今仍然遺留下許多歷史問題，比如PHP語言至今仍然無法從語言本身杜絕「文件包含漏洞」（參見這裡），只能依靠工程師良好的代碼規範和安全意識。
伴隨著Web2.0、社交網路、微博等一系列新型互聯網產品的興起，基於Web環境的互聯網應用越來越廣泛，Web攻擊的手段也越來越多樣，Web安全史上的一個重要里程碑是大約1999年發現的SQL注入攻擊，之後的XSS，CSRF等攻擊手段愈發強大，Web攻擊的思路也從服務端轉向了客戶端，轉向了瀏覽器和用戶。
在安全領域，一般用帽子的顏色來比喻黑客的善與惡，白帽子是指那些工作在反黑客領域的技術專家，這個群體是」善」的的象徵；而黑帽子則是指那些利用黑客技術造成破壞甚至謀取私利造成犯罪的群體，他們是」惡」的代表。
「白帽子」和」黑帽子」是兩個完全對立的群體。對於黑帽子而言，他們只要找到系統的一個切入點就可以達到入侵破壞的目的，而白帽子必須將自己系統所有可能被突破的地方都設防，以保證系統的安全運行。
這看起來好像是不公平的，但是安全世界裡的規則就是這樣，可能我們的網站1000處都布防的很好，考慮的很周到，但是只要有一個地方疏忽了，攻擊者就會利用這個點進行突破，讓我們另外的1000處努力白費。
常見攻擊方式
一般說來，在Web安全領域，常見的攻擊方式大概有以下幾種：
1、SQL注入攻擊
2、跨站腳本攻擊 - XSS
3、跨站偽造請求攻擊 - CSRF
4、文件上傳漏洞攻擊
5、分散式拒絕服務攻擊 - DDOS
限於篇幅，本篇只討論SQL注入攻擊的技巧與防範。
SQL注入常見攻擊技巧
SQL注入攻擊是Web安全史上的一個重要里程碑，它從1999年首次進入人們的視線，至今已經有十幾年的歷史了，雖然我們現在已經有了很全面的防範對策，但是它的威力仍然不容小覷，SQL注入攻擊至今仍然是Web安全領域中的一個重要組成部分。
以PHP+MySQL為例，讓我們以一個Web網站中最基本的用戶系統來做實例演示，看看SQL注入究竟是怎麼發生的。
1、創建一個名為demo的資料庫：
CREATE DATABASE `demo` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
2、創建一個名為user的數據表，並插入1條演示數據：
CREATE TABLE `demo`.`user` (
`uid` INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT "用戶uid",
`username` VARCHAR( 20 ) NOT NULL COMMENT "用戶名",
`password` VARCHAR( 32 ) NOT NULL COMMENT "用戶密碼"
) ENGINE = INNODB;
INSERT INTO `demo`.`user` (`uid`, `username`, `password`) VALUES ("1", "plhwin", MD5("123456"));
實例一
通過傳入username參數，在頁面列印出這個會員的詳細信息，編寫 userinfo.php 程序代碼：
",print_r($userinfo, 1),"&";&multi_query($sql);
if($query){
do {
$result = $mysqli-&>store_result();
while($row = $result-&>fetch_assoc()){
$userinfo[] = $row;
}
if(!$mysqli-&>more_results()){
break;
}
} while ($mysqli-&>next_result());
}
}
echo "&
上面這個程序要實現的功能是根據瀏覽器傳入的用戶名參數，在頁面上列印出這個用戶的詳細信息，程序寫的這麼複雜是因為我採用了mysqli的驅動，以便能使用到 multi_query 方法來支持同時執行多條SQL語句，這樣能更好的說明SQL注入攻擊的危害性。
假設我們可以通過 http://localhost/test/userinfo.php?username=plhwin 這個URL來訪問到具體某個會員的詳情，正常情況下，如果瀏覽器里傳入的username是合法的，那麼SQL語句會執行：
SELECT uid,username FROM user WHERE username="plhwin"
但是，如果用戶在瀏覽器里把傳入的username參數變為 plhwin";SHOW TABLES-- hack，也就是當URL變為 http://localhost/test/userinfo.php?username=plhwin";SHOW TABLES-- hack 的時候，此時我們程序實際執行的SQL語句變成了：
SELECT uid,username FROM user WHERE username="plhwin";SHOW TABLES-- hack"
注意：在MySQL中，最後連續的兩個減號表示忽略此SQL減號後面的語句，我本機的MySQL版本號為5.6.12，目前幾乎所有SQL注入實例都是直接採用兩個減號結尾，但是實際測試，這個版本號的MySQL要求兩個減號後面必須要有空格才能正常注入，而瀏覽器是會自動刪除掉URL尾部空格的，所以我們的注入會在兩個減號後面統一添加任意一個字元或單詞，本篇文章的SQL注入實例統一以 -- hack 結尾。
經過上面的SQL注入後，原本想要執行查詢會員詳情的SQL語句，此時還額外執行了 SHOW TABLES; 語句，這顯然不是開發者的本意，此時可以在瀏覽器里看到頁面的輸出：
Array
(
[0] =&> Array
(
[uid] =&> 1
[username] =&> plhwin
)
[1] =&> Array
(
[Tables_in_demo] =&> user
)
)
你能清晰的看到，除了會員的信息，資料庫表的名字user也被列印在了頁面上，如果作惡的黑客此時將參數換成 plhwin";DROP TABLE user-- hack，那將產生災難性的嚴重結果，當你在瀏覽器中執行 http://localhost/test/userinfo.php?username=plhwin";DROP TABLE user-- hack 這個URL後，你會發現整個 user 數據表都消失不見了。
通過上面的例子，大家已經認識到SQL注入攻擊的危害性，但是仍然會有人心存疑問，MySQL默認驅動的mysql_query方法現在已經不支持多條語句同時執行了，大部分開發者怎麼可能像上面的演示程序那樣又麻煩又不安全。
是的，在PHP程序中，MySQL是不允許在一個mysql_query中使用分號執行多SQL語句的，這使得很多開發者都認為MySQL本身就不允許多語句執行了，但實際上MySQL早在4.1版本就允許多語句執行，通過PHP的源代碼，我們發現其實只是PHP語言自身限制了這種用法，具體情況大家可以看看這篇文章「PHP+MySQL多語句執行」。
實例二
如果系統不允許同時執行多條SQL語句，那麼SQL注入攻擊是不是就不再這麼可怕呢？答案是否定的，我們仍然以上面的user數據表，用Web網站中常用的會員登錄系統來做另外一個場景實例，編寫程序login.php，代碼如下：
&",print_r($userinfo, 1),"&";
} else {
echo "用戶名不存在或密碼錯誤！";
}
}
?&>
&
&
&
&
&
&
&
&
※為什麼知乎點擊登錄過後才填寫驗證碼？
※怎樣防範被人肉搜索？
※未來安全公司會消亡嗎？為什麼？
※360在安全領域的真實實力是怎麼樣的？
※我可以用新浪微博登錄第三方平台，是否意味著我的用戶名和密碼已經被新浪送給了第三方？