① 如何防止SQL注入，並通過腳本來過濾SQL中注入的字元
如果您通過網頁獲取用戶輸入的數據並將其插入一個MySQL資料庫，那麼就有可能專發生屬SQL注入安全的問題。
本章節將為大家介紹如何防止SQL注入，並通過腳本來過濾SQL中注入的字元。
http://e.cnzz.cn/201509/96863872.shtml
② sql注入 安全測試 靠參數過濾可行嗎
首先：我們要了解SQL收到一個指令後所做的事情：具體細節可以查看文章：SqlServer編譯、重編譯與執行計劃重用原理在這里，我簡單的表示為：收到指令->編譯SQL生成執行計劃->選擇執行計劃->執行執行計劃。具體可能有點不一樣，但大致的步驟如上所示。接著我們來分析為什麼拼接SQL字元串會導致SQL注入的風險呢？首先創建一張表Users:CREATETABLE[dbo].[Users]([Id][uniqueidentifier]NOTNULL,[UserId][int]NOTNULL,[UserName][varchar](50)NULL,[Password][varchar](50)NOTNULL,CONSTRAINT[PK_Users]PRIMARYKEYCLUSTERED([Id]ASC)WITH(PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY])ON[PRIMARY]插入一些數據：INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),1,'name1','pwd1');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),2,'name2','pwd2');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),3,'name3','pwd3');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),4,'name4','pwd4');INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),5,'name5','pwd5');假設我們有個用戶登錄的頁面，代碼如下：驗證用戶登錄的sql如下：selectCOUNT(*)fromUserswherePassword='a'andUserName='b'這段代碼返回Password和UserName都匹配的用戶數量，如果大於1的話，那麼就代表用戶存在。本文不討論SQL中的密碼策略，也不討論代碼規范，主要是講為什麼能夠防止SQL注入，請一些同學不要糾結與某些代碼，或者和SQL注入無關的主題。可以看到執行結果：這個是SQLprofile跟蹤的SQL語句。注入的代碼如下：selectCOUNT(*)fromUserswherePassword='a'andUserName='b'or1=1—'這里有人將UserName設置為了「b'or1=1–」.實際執行的SQL就變成了如下：可以很明顯的看到SQL注入成功了。很多人都知道參數化查詢可以避免上面出現的注入問題，比如下面的代碼：classProgram{="DataSource=.;InitialCatalog=Test;IntegratedSecurity=True";staticvoidMain(string[]args){Login("b","a");Login("b'or1=1--","a");}privatestaticvoidLogin(stringuserName,stringpassword){using(SqlConnectionconn=newSqlConnection(connectionString)){conn.Open();SqlCommandcomm=newSqlCommand();comm.Connection=conn;//為每一條數據添加一個參數comm.CommandText="selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName";comm.Parameters.AddRange(newSqlParameter[]{newSqlParameter("@Password",SqlDbType.VarChar){Value=password},newSqlParameter("@UserName",SqlDbType.VarChar){Value=userName},});comm.ExecuteNonQuery();}}}實際執行的SQL如下所示：execsp_executesqlN'selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName',N'@Passwordvarchar(1),@UserNamevarchar(1)',@Password='a',@UserName='b'execsp_executesqlN'selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName',N'@Passwordvarchar(1),@UserNamevarchar(11)',@Password='a',@UserName='b''or1=1—'可以看到參數化查詢主要做了這些事情：1：參數過濾，可以看到@UserName='b''or1=1—'2：執行計劃重用因為執行計劃被重用，所以可以防止SQL注入。首先分析SQL注入的本質，用戶寫了一段SQL用來表示查找密碼是a的，用戶名是b的所有用戶的數量。通過注入SQL，這段SQL現在表示的含義是查找(密碼是a的，並且用戶名是b的，)或者1=1的所有用戶的數量。可以看到SQL的語意發生了改變，為什麼發生了改變呢？，因為沒有重用以前的執行計劃，因為對注入後的SQL語句重新進行了編譯，因為重新執行了語法解析。所以要保證SQL語義不變，即我想要表達SQL就是我想表達的意思，不是別的注入後的意思，就應該重用執行計劃。如果不能夠重用執行計劃，那麼就有SQL注入的風險，因為SQL的語意有可能會變化，所表達的查詢就可能變化。在SQLServer中查詢執行計劃可以使用下面的腳本：DBCCFreeProccacheselecttotal_elapsed_time/execution_count平均時間,total_logical_reads/execution_count邏輯讀,usecounts重用次數,SUBSTRING(d.text,(statement_start_offset/2)+1,((CASEstatement_end_offsetWHEN-1THENDATALENGTH(text)ELSEstatement_end_offsetEND-statement_start_offset)/2)+1)語句執行fromsys.dm_exec_cached_plansacrossapplysys.dm_exec_query_plan(a.plan_handle)c,sys.dm_exec_query_statsbcrossapplysys.dm_exec_sql_text(b.sql_handle)d--wherea.plan_handle=b.plan_handleandtotal_logical_reads/execution_count>4000ORDERBYtotal_elapsed_time/execution_countDESC;
③ 過濾單引號後是否sql注入就無解了
也不能這樣說，要過濾的內容很多，如注釋 -- ，exec delete select update 基本的都要過濾，但這不是回治本的，答如果16進制攻擊也會出問題。
最好的辦法就是使用參數方式來處理SQL，絕不要拼字元
16進制：
http://www.cnblogs.com/liyongfisher/archive/2010/12/20/1911432.html
參數化處理：
http://www.cnblogs.com/lzrabbit/archive/2012/04/21/2460978.html
④ 如何徹底防止SQL注入
1、對，限制用戶輸入肯定有效
2、應該也可以做到，但正則不是一種高效的方法，用HtmlEncode的方法可以有效防止空格等被DBMS解釋，但注意別把編碼、解碼搞反了；存儲過程是DBMS執行的一段程序，把數據操縱交給存儲過程執行，而不是提交SQL語句，可以有效防止SQL注入。
3、地址欄的Sql攻擊，下面我引用了一段資料解釋，他關於機制說的較清楚，關於解決，只是從客戶端考慮的，實際上用存儲過程等都可以防範。
資料：
首先，入侵者會對一個網站確定可不可以進行注入，假設一篇文章的地址為：http://www.naohou.cn/show.asp?id=325一般會以提交兩個地址來測試，如：
http://www.naohou.cn/show.asp?id=325 and 1=1
http://www.naohou.cn/show.asp?id=325 and 1=2
第一個地址後面加了 and 1=1，構成的SQL語句也就變為了：Select * from 表單名 where id=1 and 1=1這句話要成立就必須and前後語句都成立。那麼前面的文章地址是可以訪問的，後面的1=1也是客觀成立的，那麼第一個地址就可以正常顯示；相反1=2是顯然不成立的，關鍵就看這步了，如果提交and 1=2頁面還是正常顯示說明他並沒有將and 1=2寫入SQL語句，此站也就不存在注入漏洞；但如果提交and 1=2之後返回了錯誤頁面則說明此站點將後面的語句帶入了SQL語句並執行了，也就說明他可以進行SQL注入。（註：如果地址後面跟的是news.asp?id='1'就得變為news.asp?id=1' and '1'='1來補全引號了）
那麼，知道可以注入後入侵者可以做什麼呢？
這里就簡單的說一下，比如提交這樣的地址：
http://www.naohou.cn/show.asp?id=325 and exists (select * from 表名 where 列名=數據)
根據返回的正確或錯誤頁面來判斷猜的表名和列名是否正確，具體實現時是先猜表名再猜列名。當猜出表名和列名之後還可以用ASC和MID函數來猜出各列的數據。MID函數的格式為：mid(變數名,第幾個字元開始讀取,讀取幾個字元)，比如：mid(pwd,1,2)就可以從變數pwd中的第一位開始讀取兩位的字元。ASC函數的格式為：ASC（"字元串"），如：asc("a")就可以讀出字母a的ASCII碼了。那麼實際應用的時候就可以寫為：asc(mid(pwd,1,1))這樣讀取的就是pwd列的第一個字元的ASCII碼，提交： asc(mid(pwd,1,1))>97以返回的頁面是否為正確頁面來判斷pwd列的第一個字元的ASCII碼是否大於97（a的ASCII碼），如果正確就再試是否小於122（z的ASCII碼）……這樣慢慢縮小字元的ASCII碼的范圍，猜到真實的ASCII碼也只是時間的問題。一位一位的猜就可以得到資料庫中的用戶名和密碼了。還有一種ASP驗證缺陷——就是用戶名和密碼都輸'or '1'='1，構造SQL語句Select * form 表單名 where username='' or '1'='1' and pwd='' or '1'='1'就可以達到繞過密碼驗證的目的。
說了那麼多，其實防範的方法很簡單，我們把特殊字元（如and、or、'、"）都禁止提交就可以防止注入了。ASP傳輸數據分為get和post兩種， get是通過將數據添加到URL後提交的方式，post則是利用郵寄信息數據欄位將數據傳送到伺服器。
⑤ 如何手動繞過SQL注入過濾器
開始。運行.services.msc,服務管理的，這么多服務，那如何找到那個才是呢，
那可以去運行VM虛擬機，會提某某服務被禁用，請開啟的字樣，那首字母按下即可。
⑥ sql注入 form過濾怎麼繞過
我常用的三種方法復：
1，參數制過濾，過濾掉 單引號，or，1=1 等類似這樣的 。
2，使用 參數化方法格式化 ，不使用拼接SQL 語句。
3，主要業務使用存儲過程，並在代碼里使用參數化來調用（存儲過程和方法2結合）
⑦ 『求指導』網站過濾了sql注入怎麼整
防止SQL注入式攻擊，一般都會採用參數化編程，即一些拼接性的條件改成用參數化的佔位符來代替就可以防止SQL注入攻擊。
1)C#
using(SqlCommandcom=con.CreateCommand()){
com.CommandType=CommandType.Text;
com.CommandText="UPDATEEmployeeSETTitle=@title"+
"WHEREId=@Employeeid";
//.
SqlParameterp1=com.CreateParameter();
p1.ParameterName="@title";
p1.SqlDbType=SqlDbType.VarChar;
p1.Value=title;
com.Parameters.Add(p1);
//.
com.Parameters.Add("@Employeeid",SqlDbType.Int).Value=employeeID;
//.
intresult=com.ExecuteNonQuery();
}2)JAVA
PreparedStatementpstmt=null;
try{
StringSQL="UpdateEmployeesSETage=?WHEREid=?";
pstmt=conn.prepareStatement(SQL);
pstmt.setInt(1,yourvalue);//對應第1個？號
pstmt.setString(2,yourvalue);//對應第2個？號
}
catch(SQLExceptione){
...
}
finally{
...
}
⑧ 求助，關於SQL注入如何繞過SELECT語句的過濾
1,：轉換抄個別字母大小寫，無襲效
2：輸入SESELECTLECT之類的語句來代替SELECT，無效
3：用轉義的URL編碼來代替SELECT（不知道這么表述對不對，就是%後面跟上16進制的ascii碼……），無效
4：用/**/來隔開SELECT中的各個字母，無效
⑨ 下列哪個漏洞不是由於未對輸入做過濾造成的 A、Dos攻擊 B、SQL注入 C、日誌注入 D、命令行注入
SQL 注入 例如萬能密碼 or 1=1
⑩ C/S系統也應該有防止SQL注入處理嗎
是否會有sql注入的漏洞與c/s還是b/s無關，和後台執行sql的方式有關
例如畫面上一個框A，值是abc，如果直接將其拼成 select * from 表1 where A='abc'然後用executeQuery()之類的方式執行，那麼就無可避免的有sql注入風險
如果採用參數化的方式或者存儲過程就可以有效避免這個問題
比如set @A='abc' select * from 表1 where A=@A