sql注入解決

① mybatis中的$的sql注入該怎麼解決

#{ } 解析為一個 JDBC 預編譯語句（prepared statement）的參數標記符。
例如，sqlMap 中如下的 sql 語句
select * from user where name = #{name};

解析為：
select * from user where name = ?;

一個 #{ } 被解析為一個參數佔位符 ? 。
${ } 僅僅為一個純碎的 string 替換，在動態 SQL 解析階段將會進行變數替換
例如，sqlMap 中如下的 sql
select * from user where name = '${name}';

當我們傳遞的參數為 "ruhua" 時，上述 sql 的解析為：
select * from user where name = "ruhua";

預編譯之前的 SQL 語句已經不包含變數 name 了。
綜上所得， ${ } 的變數的替換階段是在動態 SQL 解析階段，而 #{ }的變數的替換是在 DBMS 中。
注意：${ } 在預編譯之前已經被變數替換了，這會存在 sql 注入問題。

② 什麼是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()等，但是這些函數並非一勞永逸，攻擊者還可以通過一些特殊的方式繞過。

③ 網站資料庫被SQL注入後應該怎麼辦

之前做過了一個網站，由於沒有對頁面參數進行驗證，掛上去沒多長時間就被人掛馬了，資料庫的每個表每個欄位內容里都被注入了一段代碼，什麼在資料庫中還新建了自己的表，真是太囂張了，但是這么多內容是不可能手動去刪除的，解決過程如下

一、首先刪除資料庫被注入的代碼

如統一刪除<script src=http://3b3.org/c.js> </script> （此適用於sql server）

DECLAREhCForEachCURSORGLOBAL
FOR
SELECTN'update'+QUOTENAME(o.name)
+N'set'+QUOTENAME(c.name)+N'=replace(CAST('+QUOTENAME(c.name)+'asvarchar(8000)),''<scriptsrc=http://3b3.org/c.js></script>'','''')'
FROMsysobjectso,syscolumnsc,systypest
WHEREo.id=c.id
ANDOBJECTPROPERTY(o.id,N'IsUserTable')=1
ANDc.xusertype=t.xusertype
AND(t.name='varchar'ort.name='ntext')
EXECsp_MSforeach_Worker@command1=N'?'

注意這樣刪除之後 ntext欄位將被截斷成8000個字元 導致數據丟失，當然其實在sql注入之前這種欄位屬性已經被截斷了，所以在刪除這些之後還要進行數據恢復但是 網站被掛馬往往是隨機的不知道什麼時候 我們可能沒有做及時的備份，無法恢復

這時候我們可以考慮從資料庫日誌進行恢復

1，如果誤操作之前存在一個全庫備份（或已有多個差異備份或增量備份），首先要做的事就是進進行一次日誌備份（如果為了不讓日誌文件變大而置trunc. log on chkpt.選項為1那你就死翹了）

backuplogdbNametodisk='fileName'

2，恢復一個全庫備份，注意需要使用with norecovery，如果還有其他差異或增量備份，則逐個恢復

restoredatabasedbNamefromdisk='fileName'withnorecovery

3，恢復最後一個日誌備份即剛做的日誌備份，指定恢復時間點到誤操作之前的時刻

restorelogdbNamefromdisk='fileName'
withstopat='date_time'

最後就是把網站的漏洞補上 對參數進行過濾

④ sql注入攻擊怎麼解決

網路：

SQL注入攻擊是你需要擔心的事情，不管你用什麼web編程技術，再說所有的web框架都需要擔心這個的。你需要遵循幾條非常基本的規則：
1）在構造動態SQL語句時，一定要使用類安全（type-safe）的參數加碼機制。大多數的數據API，包括ADO和ADO. NET，有這樣的支持，允許你指定所提供的參數的確切類型（譬如，字元串，整數，日期等），可以保證這些參數被恰當地escaped/encoded了，來避免黑客利用它們。一定要從始到終地使用這些特性。
例如，在ADO. NET里對動態SQL，你可以象下面這樣重寫上述的語句，使之安全：
Dim SSN as String = Request.QueryString("SSN")
Dim cmd As new SqlCommand("SELECT au_lname,au_fname FROM authors WHERE au_id = @au_id")
Dim param = new SqlParameter("au_id",SqlDbType.VarChar)
param.Value = SSN
cmd.Parameters.Add(param)
這將防止有人試圖偷偷注入另外的SQL表達式（因為ADO. NET知道對au_id的字元串值進行加碼），以及避免其他數據問題（譬如不正確地轉換數值類型等）。注意，VS 2005內置的TableAdapter/DataSet設計器自動使用這個機制，ASP. NET 2.0數據源控制項也是如此。
一個常見的錯誤知覺（misperception）是，假如你使用了存儲過程或ORM，你就完全不受SQL注入攻擊之害了。這是不正確的，你還是需要確定在給存儲過程傳遞數據時你很謹慎，或在用ORM來定製一個查詢時，你的做法是安全的。
2） 在部署你的應用前，始終要做安全審評（security review）。建立一個正式的安全過程（formal security process），在每次你做更新時，對所有的編碼做審評。後面一點特別重要。很多次我聽說開發隊伍在正式上線（going live）前會做很詳細的安全審評，然後在幾周或幾個月之後他們做一些很小的更新時，他們會跳過安全審評這關，推說，「就是一個小小的更新，我們以後再做編碼審評好了」。請始終堅持做安全審評。
3） 千萬別把敏感性數據在資料庫里以明文存放。我個人的意見是，密碼應該總是在單向（one-way)hashed過後再存放，我甚至不喜歡將它們在加密後存放。在默認設置下，ASP. NET 2.0 Membership API 自動為你這么做，還同時實現了安全的SALT 隨機化行為（SALT randomization behavior）。如果你決定建立自己的成員資料庫，我建議你查看一下我們在這里發表的我們自己的Membership provider的源碼。同時也確定對你的資料庫里的信用卡和其他的私有數據進行了加密。這樣即使你的資料庫被人入侵（compromised）了的話，起碼你的客戶的私有數據不會被人利用。
4）確認你編寫了自動化的單元測試，來特別校驗你的數據訪問層和應用程序不受SQL注入攻擊。這么做是非常重要的，有助於捕捉住（catch）「就是一個小小的更新，所有不會有安全問題」的情形帶來的疏忽，來提供額外的安全層以避免偶然地引進壞的安全缺陷到你的應用里去。
5）鎖定你的資料庫的安全，只給訪問資料庫的web應用功能所需的最低的許可權。如果web應用不需要訪問某些表，那麼確認它沒有訪問這些表的許可權。如果web應用只需要只讀的許可權從你的account payables表來生成報表，那麼確認你禁止它對此表的 insert/update/delete 的許可權。
6）很多新手從網上下載SQL通用防注入系統的程序，在需要防範注入的頁面頭部用 來防止別人進行手動注入測試（。
可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾，你的管理員賬號及密碼就會被分析出來。
7）對於注入分析器的防範，筆者通過實驗，發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中，發現軟體並不是沖著「admin」管理員賬號去的，而是沖著許可權（如flag=1）去的。這樣一來，無論你的管理員賬號怎麼變都無法逃過檢測。
第三步：既然無法逃過檢測，那我們就做兩個賬號，一個是普通的管理員賬號，一個是防止注入的賬號，為什麼這么說呢？筆者想，如果找一個許可權最大的賬號製造假象，吸引軟體的檢測，而這個賬號里的內容是大於千字以上的中文字元，就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。
⒈對表結構進行修改。將管理員的賬號欄位的數據類型進行修改，文本型改成最大欄位255（其實也夠了，如果還想做得再大點，可以選擇備注型），密碼的欄位也進行相同設置。
⒉對表進行修改。設置管理員許可權的賬號放在ID1，並輸入大量中文字元（最好大於100個字）。
⒊把真正的管理員密碼放在ID2後的任何一個位置（如放在ID549上）。
由於SQL注入攻擊針對的是應用開發過程中的編程不嚴密，因而對於絕大多數防火牆來說，這種攻擊是「合法」的。問題的解決只有依賴於完善編程。專門針對SQL注入攻擊的工具較少，Wpoison對於用asp，php進行的開發有一定幫助...。

⑤ SQL注入怎麼防範

SQL注入攻擊的危害很大，而且防火牆很難對攻擊行為進行攔截，主要的SQL注入攻擊防範方法，具體有以下幾個方面：
1、分級管理
對用戶進行分級管理，嚴格控制用戶的許可權，對於普通用戶，禁止給予資料庫建立、刪除、修改等相關許可權，只有系統管理員才具有增、刪、改、查的許可權。
2、參數傳值
程序員在書寫SQL語言時，禁止將變數直接寫入到SQL語句，必須通過設置相應的參數來傳遞相關的變數。從而抑制SQL注入。數據輸入不能直接嵌入到查詢語句中。同時要過濾輸入的內容，過濾掉不安全的輸入數據。或者採用參數傳值的方式傳遞輸入變數，這樣可以最大程度防範SQL注入攻擊。
3、基礎過濾與二次過濾
SQL注入攻擊前，入侵者通過修改參數提交and等特殊字元，判斷是否存在漏洞，然後通過select、update等各種字元編寫SQL注入語句。因此防範SQL注入要對用戶輸入進行檢查，確保數據輸入的安全性，在具體檢查輸入或提交的變數時，對於單引號、雙引號、冒號等字元進行轉換或者過濾，從而有效防止SQL注入。
當然危險字元有很多，在獲取用戶輸入提交參數時，首先要進行基礎過濾，然後根據程序的功能及用戶輸入的可能性進行二次過濾，以確保系統的安全性。
4、使用安全參數
SQL資料庫為了有效抑制SQL注入攻擊的影響。在進行SQLServer資料庫設計時設置了專門的SQL安全參數。在程序編寫時應盡量使用安全參數來杜絕注入式攻擊，從而確保系統的安全性。
5、漏洞掃描
為了更有效地防範SQL注入攻擊，作為系統管理除了設置有效的防範措施，更應該及時發現系統存在SQL攻擊安全漏洞。系統管理員可以采購一些SQL漏洞掃描工具，通過專業的掃描工具，可以及時的掃描到系統存在的相應漏洞。
6、多層驗證
現在的網站系統功能越來越龐大復雜。為確保系統的安全，訪問者的數據輸入必須經過嚴格的驗證才能進入系統，驗證沒通過的輸入直接被拒絕訪問資料庫，並且向上層系統發出錯誤提示信息。同時在客戶端訪問程序中驗證訪問者的相關輸入信息，從而更有效的防止簡單的SQL注入。但是如果多層驗證中的下層如果驗證數據通過，那麼繞過客戶端的攻擊者就能夠隨意訪問系統。因此在進行多層驗證時，要每個層次相互配合，只有在客戶端和系統端都進行有效的驗證防護，才能更好地防範SQL注入攻擊。
7、資料庫信息加密
傳統的加解密方法大致分為三種：對稱加密、非對稱加密、不可逆加密。

⑥ php中防止SQL注入，該如何解決

防sql注入的一個簡單方法就是使用框架，一般成熟框架中會集成各種安全措施。

當然也可以自己處理，如果用戶的輸入能直接插入到SQL語句中，那麼這個應用就易收到SQL注入的攻擊。我認為最重要的一點，就是要對數據類型進行檢查和轉義。

php.ini

------------

display_errors 選項，應該設為display_errors = off。這樣 php 腳本出錯之後，不會在 web 頁面輸出錯誤，以免讓攻擊者分析出有作的信息。

打開magic_quotes_gpc來防止SQL注入，magic_quotes_gpc= Off，這個默認是關閉的，如果它打開後將自動把用戶提交對sql的查詢進行轉換，比如把 ' 轉為 '等，對於防止sql注射有重大作用。如果magic_quotes_gpc=Off，則使用addslashes()函數。

mysql 函數

---------------

調用mysql_query 等mysql 函數時，前面應該加上 @，即 @mysql_query(...)，這樣 mysql 錯誤不會被輸出。同理以免讓攻擊者分析出有用的信息。另外，有些程序員在做開發時，當mysql_query出錯時，習慣輸出錯誤以及sql 語句。

mysql_real_escape_string -- 轉義 SQL 語句中使用的字元串中的特殊字元，並考慮到連接的當前字元集。

Sql語句

------------

對提交的 sql 語句，進行轉義和類型檢查。如果請求是數值型，那麼調用is_numeric() 判斷是否為數值。如果不是，則返回程序指定的默認值。簡單起見，對於文本串，我將用戶輸入的所有危險字元（包括HTML代碼），全部轉義。由於php 函數addslashes()存在漏洞，我用str_replace()直接替換。get_magic_quotes_gpc()函數是php 的函數，用來判斷magic_quotes_gpc 選項是否打開。

其它

---------

使用預處理語句和參數化查詢（PDO或mysqli）。預處理語句和參數分別發送到資料庫伺服器進行解析，參數將會被當作普通字元處理。這種方式使得攻擊者無法注入惡意的SQL。