預編譯sql語句可以注入嗎
A. php 使用mysql 的prepare預編譯,下面這段代碼有防sql注入的功能么請高手賜教
sql注入怎麼回事:說白了就是在一個單引號上做文章,你把單引號轉義就沒啥問題了,預編譯就是把這些字元轉義後插入,其中包括單引號。
這段可以防止.
B. SQL注入預編譯是絕對安全的么
沒錯,存儲過程的確能有效解決SQL注入式攻擊!
理由:因為通常的資料庫訪問方法,都是把訪問數據表的權利賦給程序,注入式攻擊者通過你的程序漏洞判斷和獲得更多的信息,並利用你賦給程序的訪問和操作權,輕者破壞本表數據,重者毀壞整個資料庫!
使用存儲過程則完全不同,程序中不必再有SQL語句,因此程序不必擁有訪問和操作數據表的許可權,只把運行存儲過程的許可權交給程序。程序只是把參數和存儲過程名告訴資料庫,然後等待結果就行了,注入式攻擊者要想運行存儲過程,就必需猜對存儲過程名,並且還要猜對參數個數、參數名和參數的順序,同時滿足這些條件太難了,即便所以條件都滿足,那麼攻擊者也只是往數據表裡存了一組合法數據而已,不會導致其它破壞。
因此,通過存儲過程能從根本上解決注入式攻擊。
需要注意的是,使用存儲過程後,應把原來交給程序的操作數據表的許可權收回,否則就象為了防小偷鎖了前門,卻開著後門一樣。
C. 什麼是sql注入,如何防止sql注入
SQL注入,就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串,最終達到欺騙伺服器執行惡意的SQL命令。具體來說,它是利用現有應用程序,將(惡意)的SQL命令注入到後台資料庫引擎執行的能力,它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的資料庫,而不是按照設計者意圖去執行SQL語句。比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的,這類表單特別容易受到SQL注入式攻擊.
SQL注入攻擊實例:
比如在一個登錄界面,要求輸入用戶名和密碼:
可以這樣輸入實現免帳號登錄:
用戶名: 『or 1 = 1 –
密 碼:
點登陸,如若沒有做特殊處理,那麼這個非法用戶就很得意的登陸進去了.(當然現在的有些語言的資料庫API已經處理了這些問題)
這是為什麼呢? 下面我們分析一下:
從理論上說,後台認證程序中會有如下的SQL語句:
String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";
當輸入了上面的用戶名和密碼,上面的SQL語句變成:
SELECT * FROM user_table WHERE username=
'』or 1 = 1 -- and password='』
分析SQL語句:
條件後面username=」or 1=1 用戶名等於 」 或1=1 那麼這個條件一定會成功;
然後後面加兩個-,這意味著注釋,它將後面的語句注釋,讓他們不起作用,這樣語句永遠都能正確執行,用戶輕易騙過系統,獲取合法身份。
這還是比較溫柔的,如果是執行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
….其後果可想而知…
防SQL注入:
下面我針對JSP,說一下應對方法:
1.(簡單又有效的方法)PreparedStatement
採用預編譯語句集,它內置了處理SQL注入的能力,只要使用它的setXXX方法傳值即可。
使用好處:
(1).代碼的可讀性和可維護性.
(2).PreparedStatement盡最大可能提高性能.
(3).最重要的一點是極大地提高了安全性.
原理:
sql注入只對sql語句的准備(編譯)過程有破壞作用
而PreparedStatement已經准備好了,執行階段只是把輸入串作為數據處理,
而不再對sql語句進行解析,准備,因此也就避免了sql注入問題.
2.使用正則表達式過濾傳入的參數
要引入的包:
import java.util.regex.*;
正則表達式:
private String CHECKSQL = 「^(.+)\sand\s(.+)|(.+)\sor(.+)\s$」;
判斷是否匹配:
Pattern.matches(CHECKSQL,targerStr);
下面是具體的正則表達式:
檢測SQL meta-characters的正則表達式 :
/(\%27)|(』)|(--)|(\%23)|(#)/ix
修正檢測SQL meta-characters的正則表達式 :/((\%3D)|(=))[^ ]*((\%27)|(』)|(--)|(\%3B)|(:))/i
典型的SQL 注入攻擊的正則表達式 :/w*((\%27)|(』))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
檢測SQL注入,UNION查詢關鍵字的正則表達式 :/((\%27)|(』))union/ix(\%27)|(』)
檢測MS SQL Server SQL注入攻擊的正則表達式:
/exec(s|+)+(s|x)pw+/ix
等等…..
3.字元串過濾
比較通用的一個方法:
(||之間的參數可以根據自己程序的需要添加)
publicstaticbooleansql_inj(Stringstr)
{
Stringinj_str="'|and|exec|insert|select|delete|update|
count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,";
Stringinj_stra[]=split(inj_str,"|");
for(inti=0;i<inj_stra.length;i++)
{
if(str.indexOf(inj_stra[i])>=0)
{
returntrue;
}
}
returnfalse;
}
D. SQL注入的防範 使用預編譯語句
預編譯語句PreparedStatement是 java.sql中的一個介面,繼承自Statement 介面。通過Statement對象執行SQL語句時,需要將SQL語句發送給DBMS,由 DBMS先進行編譯後再執行。而預編譯語句和Statement不同,在創建PreparedStatement對象時就指定了SQL語句,該語句立即發送給DBMS進行編譯,當該編譯語句需要被執行時,DBMS直接運行編譯後的SQL語句,而不需要像其他SQL語句那樣先將其編譯。引發SQL注入的根本原因是惡意用戶將SQL指令偽裝成參數傳遞到後端資料庫執行。作為一種更為安全的動態字元串的構建方法,預編譯語句使用參數佔位符來替代需要動態傳入的參數,這樣攻擊者無法改變SQL語句的結構,SQL語句的語義不會發生改變,即便用戶傳入類似於前面' or '1'='1這樣的字元串,資料庫也會將其作為普通的字元串來處理。
E. 什麼是sql注入如何防止sql注入
SQL注入是一種非常常見的資料庫攻擊手段,同時也是網路世界中最普遍的漏洞之一,簡單理解就是惡意用戶通過在表單中填寫包含SQL關鍵字的數據來使資料庫執行非常規代碼的過程。
問題來源是,SQL資料庫的操作是通過SQL語句來執行的,而無論是執行代碼還是數據項都必須寫在SQL語句中,也就導致如果我們在數據項中加入了某些SQL語句關鍵字,比如SELECT、DROP等,這些關鍵字就很有可能在資料庫寫入或讀取數據時得到執行。
解決方案
方案一:
採用預編譯技術
使用預編譯的SQL語句,SQL語句的語義不會是不會發生改變的。預編譯語句在創建的時候就已經將指定的SQL語句發送給了DBMS,完成了解析,檢查,編譯等工作,所以攻擊者無法改變SQL語句的結構,只是把值賦給?,然後將?這個變數傳給SQL語句。當然還有一些通過預編譯繞過某些安全防護的操作,大家感興趣可以去搜索一下。
方案二:
嚴格控制數據類型
在java、c等強類型語言中一般是不存在數字型注入的,因為在接受到用戶輸入id時,代碼一般會做一個int id 的數據類型轉換,假如我們輸入的是字元串的話,那麼這種情況下,程序就會報錯。但是在PHP、ASP這些沒有強調處理數據類型的語言,一般我們看到的接收id的代碼都是如下等代碼。
方案三:
對特殊的字元進行轉義
數字型注入可以通過檢查數據類型防止,但是字元型不可以,那麼怎麼辦呢,最好的辦法就是對特殊的字元進行轉義了。比如在MySQL中我們可以對" '
"進行轉義,這樣就防止了一些惡意攻擊者來閉合語句。當然我們也可以通過一些安全函數來轉義特殊字元。如addslashes()等,但是這些函數並非一勞永逸,攻擊者還可以通過一些特殊的方式繞過。
F. 防止sql注入的方法有哪些
根據本人實際經驗總結,非照搬教科書。一種就是在伺服器上安裝安全軟體,這種安全軟體能夠自動識別注入攻擊,並做出響應策略。再就是你的所有request都要進行程序過濾,把包含sql的一些特殊字元都過濾掉。第三就是資料庫sql語句可以採用一些預編譯的框架,如Mybatis,也能防止sql注入。
G. 用java PreparedStatement就不用擔心sql注入了嗎
SQL Injection:是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串,最終達到欺騙伺服器執行惡意的SQL命令
select * from tab_name where name= '"+name+"' and passwd='"+passwd+"';
把其中passwd換成 [' or '1' = '1] 這樣就可以完成sql注入
PreparedStatement 對象用於執行帶或不帶參數的預編譯 SQL 語句
PreparedStatement 不允許在不同的插入時間改變查詢的邏輯結構,所以這種注入方式無效
H. 用預編譯的方式查詢是不是能夠杜絕SQL注入
是的,預編譯有個類是PreparedStatement.
這個類的對象是通過參數?來傳值的
例:
String sql = "select * from table where id = ?";
Connection con = .....///這里得到是資料庫的連接
PreparedStatement ps = con.prepareStatement(sql);
ps.setInt(1,id);//這里的資料庫語句所用到的參數要被設置的,如果你傳入了錯的值,或不同類型的值,它在插入到資料庫語句中會編譯不通過,這也就防止了SQL注入。
I. sql 注入問題。判斷sql 是否存在注入的關鍵是什麼呢只看sql語句還是其他的呢
最好不要這么用,明顯的注入,不要直接把值寫到語句中,用變數會好一點.
J. 如何從根本上防止 sql 注入
參數化sql語句
請採納!
具體原因,請採納以下信息:
針對於SQL注入,則是用戶提交的數據,被資料庫系統編譯而產生了開發者預期之外的動作。也就是,SQL注入是用戶輸入的數據,在拼接SQL語句的過程中,超越了數據本身,成為了SQL語句查詢邏輯的一部分,然後這樣被拼接出來的SQL語句被資料庫執行,產生了開發者預期之外的動作。
所以從根本上防止上述類型攻擊的手段,還是避免數據變成代碼被執行,時刻分清代碼和數據的界限。而具體到SQL注入來說,被執行的惡意代碼是通過資料庫的SQL解釋引擎編譯得到的,所以只要避免用戶輸入的數據被資料庫系統編譯就可以了。
現在的資料庫系統都提供SQL語句的預編譯(prepare)和查詢參數綁定功能,在SQL語句中放置佔位符'?',然後將帶有佔位符的SQL語句傳給資料庫編譯,執行的時候才將用戶輸入的數據作為執行的參數傳給用戶。這樣的操作不僅使得SQL語句在書寫的時候不再需要拼接,看起來也更直接,而且用戶輸入的數據也沒有機會被送到資料庫的SQL解釋器被編譯執行,也不會越權變成代碼。
至於為什麼這種參數化的查詢方式沒有作為默認的使用方式,我想除了兼容老系統以外,直接使用SQL確實方便並且也有確定的使用場合。
多說一點,從代碼的角度來看,拼接SQL語句的做法也是不恰當的。