如何從根本上防止 SQL 注入？

1樓：謝卓晉

我覺得最徹底地就是把使用者的輸入和和要拼接的sql的語句過一次詞法分析就好了，如果語意與預期的不一樣那就是有sql注入咯。

2樓：

說一下pymsql在拼接sql語句的做法。

大概的sql語句是

INSERT

INTO

`users`(

`username`,

`password`,

`email`)

VALUES(%

s,%s

,%s);

其中%s是輸入。

pymysql執行

cursor

.execute

(sql_string,(

username

,password

,email

))pymysql會對這樣的sql語句進行安全處理，大致涉及到兩個方法

obj是傳入的username這些的

s是傳入的username這些的

def escape_string(self, sif (self.server_status &SERVER_STATUS.SERVER_STATUS_NO_BACKSLASH_ESCAPESreturn s.

replace("'", "''"return converters.escape_string(s)

所以實際pymysql的做法是在傳入的資料前後加上"'"，並將傳入資料中可能存在的"'"替換為"''"，這樣就會被整體識別為資料字串

當然實際上還會有別的情況存在，按規範使用庫就是了

3樓：孤獨的探索號

再好的方式都防不了無知、懶惰、不負責任。

所以後端不寫介面、不寫SQL就好了。

前端傳JSON，後端自動生成預編譯的SQL語句，自動執行後返回對應結構的JSON。

通過自動化API，前端可以定製任何資料、任何結構！

大部分HTTP請求後端再也不用寫介面了，更不用寫文件了！

前端再也不用和後端溝通介面或文件問題了！再也不會被文件各種錯誤坑了！

後端再也不用為了相容舊介面寫新版介面和文件了！再也不會被前端隨時隨地沒完沒了地煩了！

TommyLemon/APIJSON

4樓：是瘋子真好

其實很簡單，進行轉碼是最快的解決方式

每個字元轉成二進位制，通過「,」進行分割，讀取的時候進行解析如果不在乎速度的可以考慮這個做法

再者……nosql —— nosql注入

5樓：蔣蔣蔣校長

我認為至少從兩方面我們可以入手：

1.使用者輸入，即從使用者端向服務端傳的資料，如API引數，網頁FORM表單等，大部分的入侵前題由使用者對輸入資料進行處理以得到其目的的

2.後端使用基於非SQL的資料儲存，根本上避免後端使用SQL語句，如資料庫使用NOSQL，在NOSQL日現成熟的當下這個不失為乙個好方案

6樓：darkread lee

題主問的是為什麼還是怎麼做？

為什麼會發生？因為開發者沒有嚴格按照標準進行。資料庫是乙個產品，sql不是作為某個軟體的基礎存在的，看看sql的全稱就知道了。

至於怎麼做？引數化？這可以杜絕大部分的問題，但不是全部，全部是驗證使用者輸入！任何不合規的輸入必須禁止，這才是根本！

7樓：楊碩

時隔很久看自己發的都感覺搞笑，目前我是這樣做的：

把每乙個引數內部的'都換成''（這樣你存進去的還是乙個'，否則會被截斷造成注入）

然後把引數兩端加個'，這樣不管傳進來的是什麼，都會被轉化為乙個正常的引數傳入。

以前提這方法的確考慮太少，弱爆了，以下是以前寫的呼叫資料庫的公共方法加一句就好了…這麼簡單的問題為毛要搞得那麼複雜…if(sql.contains("--"))

8樓：李春

對SQL注入研究的沒有各位這麼深。

補充一下個人的拙見，安全問題應該是沒有「絕對」的，只能說讓入侵的成本更高，如果從根本上避免了SQL注入，資料庫的密碼是123456，那也是沒轍的。

一般情況下用prepare就可以避免大部分問題了

9樓：李有星

通天的路需要好幾種，資料庫sql不可能規定的太呆板，應有一定的靈活性，功能要強大。到底如何使用它，要看設計客戶應用的程式設計師，sql注入本身是程式設計師的錯，而不是資料庫。

10樓：

應用層面只能通過正規表示式過濾特殊字元+PrepareStatement引數化查詢,或採用儲存過程,但網際網路應用肯定不適合採用儲存過程。

資料庫層面無解決方案。

如果真要從根本上解決這個問題，最直接的方案是採用NoSQL。

11樓：

SQL注入不是SQL的錯，是程式使用賬號登入SQL後，不適當使用造成。理應是程式自行解決。我的體會是，嚴格過濾SQL語句就行了。

但是沒有絕對。絕對就不僅僅是SQL注入這個問題了。

12樓：

同意 @Cosmia Fu 的觀點。

「SQL注入根本就不是漏洞而是功能」。

SQL語言本身就是一串字串，任何語言的資料庫連線API都必須提供直接執行SQL字串的功能。所以，從根本上，這個功能是必須存在的，也就是說SQL注入根本無法防治。

所以，問題本身就是乙個偽命題。

關鍵在於寫程式的人。

而要改變寫程式人的習慣，關鍵又在於語言學習的教學法。

想當初，無論ASP、PHP、JSP的教學文章，幾乎都是通過獲得URL中的引數，直接拼出SQL字串，然後執行。

這就是錯誤的！在誤人子弟！

所以，要解決這個問題，只能一條路，就是告訴所有人，什麼才是正確的程式設計方法。

僅此而已。

13樓：戴路

我有乙個偏方，把你的引數值加密，使用的時候再解密。

例如，原來的read.aspx?id=3就變成read.

aspx?id=hdyrhsg=54dhdhr之類的在使用這個引數時再解密 hdyrhsg=54dhdhr得到數字3，隨便怎麼拼接字串都行了。

攻擊者不知道你的金鑰，自然無法生成注入語句。

如果要考慮更安全，你還可以編寫一套金鑰生成演算法，一次一密。

14樓：Feng Guangpu

1) 應用層面解決，對於根據使用者輸入拼接而成的sql，檢查使用者輸入，只保證合法sql通過（而不是過濾delete/drop等危險關鍵字）

2）在資料庫中限制使用者許可權，drop/create/truncate等許可權謹慎grant

3）以prepared statement方式執行sql可以一定程度上防止sql注入

4）對於MySQL等開源資料庫，不允許不帶where條件(或者where條件恒為true)的delete和update，即safe update模式，通過定製patch的方式限制使用者修改的資料行數，在sql中增加hint傳遞期望修改資料的數目，如果真實更新資料與目標不符，回滾操作

5）備份很重要，即使發生這類悲劇，通過上一次備份重建資料庫和重放最近更新來挽救

15樓：Frank Meng

使用儲存過程作為應用程式訪問資料庫的唯一介面。另外，這也是唯一可以實現應用程式與資料庫松耦合的方式。

儲存過程分兩種，一種是「平直」的不需要在內部動態拼寫SQL的，這種自然不會被注入。另一種是需要在內部動態拼寫SQL的然後用sp_executesql呼叫的。sp_executesql的引數規範為：

sp_executesql @statement= 'DELETE FROM TableA WHERE ID = @ID'

,@params =N'@ID INT' --SQL語句中的引數定義

,@ID = @pID --為SQL語句中的引數賦值

只要保證在拼接@statement的過程中不使用任何從儲存過程引數傳直接進來的資料直接拼接就不會被注入，如果一定要這麼做，做一下對映即可，總之不能直接拼接。

16樓：

1. 校驗，包括客戶端校驗以及服務端校驗，比如id只能為數字，那麼輸入就必須是數字，不符合輸入要求的字元不允許連線到SQL中。

2. 許可權，在上一層次上隔離非獲得授權的訪問。

杜絕SQL注入，功夫本在SQL之外

17樓：悟空

1. 引數化查詢是訪問資料庫的驅動程式提供的，會保證引數本身只作為值，而不是作為SQL被資料庫編譯。

2.被SQL注入的唯一可能是SQL能被資料庫編譯，如果不經過此階段，能注入什麼？

18樓：pansz

要想解決這個問題很簡單，但都不是在資料庫層面的，通過程式設計框架或者詞法分析的方法本質上是在 SQL 之上再增加了乙個適配層，使用者的輸入先經過了某個適配層的處理然後才進入 SQL 語句。而引數化查詢看起來是繞開了 SQL，但不能阻止程式設計師非要使用 SQL 進行查詢。

而這些方法都違背了題主問題的本意。題主的本意不是問如何解決 SQL 注入問題，而是問能否從資料庫自身的層面解決 SQL 注入問題，但這個問題在 SQL 內不可能解決。

SQL 注入的本質在於它是乙個語言而不是乙個特定格式的API。所以你無法單獨的給它傳輸引數什麼的，只能整體的執行一條語句。只要使用者輸入的東西可以直接進入 SQL，乙個元素就可以變成一條語句，那麼 SQL 注入就無法防止。

更明確一些，這個問題並不是 SQL 語言特有的，而是只要 API 是乙個語言，這個問題就必然存在。除非這個資料庫的 API 並不以語言的方式提供，而是以某種不靈活不方便（但更安全）的方式。

我認為，要想完全從資料庫本身解決這個問題，唯一的方法只能是不用 SQL ，不使用支援 SQL 的資料庫，資料庫的 API 以某種並非文字語言的方式提供。——純粹資料庫的角度，只要用 SQL 語言發命令的這種方式仍然存在，你就沒法擋住手殘的程式設計師，除非完全禁止掉 SQL。

19樓：玩家翁偉

這事從根本上說是人的問題，提供再好的api，二逼程式設計師都有辦法把它用爛。sql能注入，不用sql？成，那html注入又怎麼說？

根本辦法就是把人給換了。

對於任何乙個合格的程式設計師來說，防止sql注入根本就不是乙個事。

20樓：Ivony

根本上杜絕的方案太多太簡單了，SQL注入這種攻擊手段說白了和直接把門踹開偷東西一樣Low，這麼多年一爆再爆我也很震精。不過想想其實都是一群小白拿著幾十年前的小白寫的東西改改用才會這樣的。

有人非說我沒回答問題，OK，根本的手段就是引數化查詢或者做詞法分析。

@pansz 的答案的確是說到了乙個關鍵，也就是如果支援文字式的指令，那這事兒是沒有辦法杜絕的，只能在外面套上乙個殼，也就是詞法分析。

但是現代資料庫卻不是只提供了SQL文字查詢，引數化查詢也是標準API之一，當然還有儲存過程，這些高階的API都可以有效的杜絕SQL注入這種問題。在MySQL都支援儲存過程的今天，還有這麼多注入漏洞實在是讓人費解。

不使用支援SQL的資料庫過於偏頗了，幾乎所有的關係型資料庫都支援SQL查詢，但也提供了安全的查詢方式。

如何從根本上防止 SQL 注入？

如何從根本上戒除網癮？

如何從根本上提高遊戲意識？

如何從根本上解決氣虛的問題？

其他用戶還看了：