sql注入過濾關鍵字

A. sql注入 form過濾怎麼繞過

我常用的三種方法：
1，參數過濾，過濾掉 單引號，or，1=1 等類似這樣的 。
2，使用 參數化方法格式化 ，不使用拼接SQL 語句。
3，主要業務使用存儲過程，並在代碼里使用參數化來調用（存儲過程和方法2結合）

B. ASP.NET 實現SQL注入過濾

一 什麼是SQL注入式攻擊 所謂SQL注入式攻擊 就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字元串 欺騙伺服器執行惡意的SQL命令 在某些表單中 用戶輸入的內容直接用來構造（或者影響）動態SQL命令 或作為存儲過程的輸入參數 這類表單特別容易受到SQL注入式攻擊 常見的SQL注入式攻擊過程類如 ⑴ 某個ASP NET Web應用有一個登錄頁面 這個登錄頁面控制著用戶是否有權訪問應用 它要求用戶輸入一個名稱和密碼 ⑵ 登錄頁面中輸入的內容好塵將直接用來構造動態的SQL命令 或者直接用作存儲過程的參數 下面是ASP NET應用構造查詢的一個例子 System Text StringBuilder query = new System Text StringBuilder（ SELECT * from Users WHERE login = ） Append（txtLogin Text） Append（ AND password= ） Append（txtPassword Text） Append（ ） ⑶ 攻擊者在用戶名字和密碼輸入框中輸入 或 = 之類的內容 ⑷ 用戶輸入的內容提交給伺服器之後 伺服器運行上猛襪清面的ASP NET代碼構造出查詢用戶的SQL命令 但由於攻擊者輸入的內容非常特殊 所以最後得到的SQL命令變成 SELECT * from Users WHERE login = or = AND password = or = ⑸ 伺服器執行查詢或存儲過程 將用戶輸入的身份信息和伺服器中保存的身份信息進行對比 ⑹ 由於SQL命令實際上已被注入式攻擊修改 已經不能真正驗證用戶身份 所以系統會錯誤地授權給攻擊者 如果攻擊者知道應用會將表單中輸入的內容直接用於驗證身份的查詢 他就會嘗試輸入某些特殊的SQL字元串篡改查詢改變其原來的功能 欺騙系統授予訪問許可權 枝前 系統環境不同 攻擊者可能造成的損害也不同 這主要由應用訪問資料庫的安全許可權決定 如果用戶的帳戶具有管理員或其他比較高級的許可權 攻擊者就可能對資料庫的表執行各種他想要做的操作 包括添加 刪除或更新數據 甚至可能直接刪除表 二 如何防範 好在要防止ASP NET應用被SQL注入式攻擊闖入並不是一件特別困難的事情 只要在利用表單輸入的內容構造SQL命令之前 把所有輸入內容過濾一番就可以了 過濾輸入內容可以按多種方式進行

⑴ 對於動態構造SQL查詢的場合 可以使用下面的技術 第一 替換單引號 即把所有單獨出現的單引號改成兩個單引號 防止攻擊者修改SQL命令的含義 再來看前面的例子 SELECT * from Users WHERE login = or = AND password = or = 顯然會得到與 SELECT * from Users WHERE login = or = AND password = or = 不同的結果 第二 刪除用戶輸入內容中的所有連字元 防止攻擊者構造出類如 SELECT * from Users WHERE login = mas AND password = 之類的查詢 因為這類查詢的後半部分已經被注釋掉 不再有效 攻擊者只要知道一個合法的用戶登錄名稱 根本不需要知道用戶的密碼就可以順利獲得訪問許可權 第三 對於用來執行查詢的資料庫帳戶 限制其許可權 用不同的用戶帳戶執行查詢 插入 更新 刪除操作 由於隔離了不同帳戶可執行的操作 因而也就防止了原本用於執行SELECT命令的地方卻被用於執行INSERT UPDATE或DELETE命令 ⑵ 用存儲過程來執行所有的查詢 SQL參數的傳遞方式將防止攻擊者利用單引號和連字元實施攻擊 此外 它還使得資料庫許可權可以限制到只允許特定的存儲過程執行 所有的用戶輸入必須遵從被調用的存儲過程的安全上下文 這樣就很難再發生注入式攻擊了 ⑶ 限製表單或查詢字元串輸入的長度 如果用戶的登錄名字最多隻有 個字元 那麼不要認可表單中輸入的 個以上的字元 這將大大增加攻擊者在SQL命令中插入有害代碼的難度 ⑷ 檢查用戶輸入的合法性 確信輸入的內容只包含合法的數據 數據檢查應當在客戶端和伺服器端都執行 之所以要執行伺服器端驗證 是為了彌補客戶端驗證機制脆弱的安全性 在客戶端 攻擊者完全有可能獲得網頁的源代碼 修改驗證合法性的腳本（或者直接刪除腳本） 然後將非法內容通過修改後的表單提交給伺服器 因此 要保證驗證操作確實已經執行 唯一的辦法就是在伺服器端也執行驗證 你可以使用許多內建的驗證對象 例如RegularExpressionValidator 它們能夠自動生成驗證用的客戶端腳本 當然你也可以插入伺服器端的方法調用 如果找不到現成的驗證對象 你可以通過CustomValidator自己創建一個 ⑸ 將用戶登錄名稱 密碼等數據加密保存 加密用戶輸入的數據 然後再將它與資料庫中保存的數據比較 這相當於對用戶輸入的數據進行了 消毒 處理 用戶輸入的數據不再對資料庫有任何特殊的意義 從而也就防止了攻擊者注入SQL命令 System Web Security FormsAuthentication類有一個 非常適合於對輸入數據進行消毒處理 ⑹ 檢查提取數據的查詢所返回的記錄數量 如果程序只要求返回一個記錄 但實際返回的記錄卻超過一行 那就當作出錯處理

以上資料參考與 賽迪網資料 但是我覺得在我們的ASP NET程序里防止SQL 注入 首先應該盡量使用存儲過程 關於使用存儲過程的好處在這里就不展開討論了 使用參數傳遞變數 最不妥當的方法就是認為判斷SQL注入信息 盡管如此 可能日常開發中由於種種原因不能做的面面具道 存在各種各種的實際問題 現在是最近在一個項目中沒有考慮SQL注入項目補救寫的一個組件庫 資料也參考來源與網路 實現很簡單 下面是具體實現的源程序 using System; using System Text RegularExpressions; using System Web; namespace FSqlKeyWord …{ /**//// <summary> /// SqlKey 的摘要說明 /// </summary> public class SqlKey …{ private HttpRequest request; private const string StrKeyWord = @ select|insert|delete|from|count（|drop table|update|truncate|asc（|mid（|char（|xp_cmdshell|exec master|netlocalgroup administrators|:|net user| |or|and ; private const string StrRegex = @ [ |;| |/|（|）|[|]|}|{|%|@|*|!| ] ; public SqlKey（System Web HttpRequest _request） …{ // // TODO: 在此處添加構造函數邏輯 // this request = _request; } /**//// <summary> /// 只讀屬性 SQL關鍵字 /// </summary> public static string KeyWord …{ get …{ return StrKeyWord; } } /**//// <summary> /// 只讀屬性過濾特殊字元 /// </summary> public static string RegexString …{ get …{ return StrRegex; } } /**//// <summary> /// 檢查URL參數中是否帶有SQL注入可能關鍵字 /// </summary> /// <param name= _request >當前HttpRequest對象</param> /// <returns>存在SQL注入關鍵字true存在 false不存在</returns> public bool CheckRequestQuery（） …{ if （request QueryString Count != ） …{ //若URL中參數存在 逐個比較參數 for （int i = ; i < request QueryString Count; i++） …{ // 檢查參數值是否合法 if （CheckKeyWord（request QueryString[i] ToString（））） …{ return true; } } } return false; } /**//// <summary> /// 檢查提交表單中是否存在SQL注入可能關鍵字 /// </summary> /// <param name= _request >當前HttpRequest對象</param> /// <returns>存在SQL注入關鍵字true存在 false不存在</returns> public bool CheckRequestForm（） …{ if （request Form Count > ） …{ //獲取提交的表單項不為 逐個比較參數 for （int i = ; i < request Form Count; i++） …{ //檢查參數值是否合法 if （CheckKeyWord（request Form[i]）） …{ //存在SQL關鍵字 return true; } } } return false; } /**//// <summary> /// 靜態方法 檢查_sword是否包涵SQL關鍵字 /// </summary> /// <param name= _sWord >被檢查的字元串</param> /// <returns>存在SQL關鍵字返回true 不存在返回false</returns> public static bool CheckKeyWord（string _sWord） …{ if （Regex IsMatch（_sWord StrKeyWord RegexOptions IgnoreCase） || Regex IsMatch（_sWord StrRegex）） return true; return false; } /**//// <summary> /// 反SQL注入 返回 無注入信息 否則返回錯誤處理 /// </summary> /// <returns>返回 無注入信息 否則返回錯誤處理</returns> public string CheckMessage（） …{ string msg = ; if （CheckRequestQuery（）） //CheckRequestQuery（） || CheckRequestForm（） …{ msg = <span style= font size: px; >非法操作！<br> ; msg += 操作IP: + request ServerVariables[ REMOTE_ADDR ] + <br> ; msg += 操作時間 + DateTime Now + <br> ; msg += 頁面 + request ServerVariables[ URL ] ToLower（） + <br> ; msg += <a # onclick= history back（） >返回上一頁</a></span> ; } return msg ToString（） } } } lishixin/Article/program/net/201311/11680

C. SQL注入步驟和常用函數以及中文處理方法

第一節 SQL注入的一般步驟 首先 判斷環境 尋找注入點 判斷資料庫類型 這在入門篇已經講過了 其次 根據注入參數類型 在腦海中重構SQL語句的原貌 按參數類型主要分為下面三種 (A)ID= 這類注入的參數是數字型 SQL語句原貌大致如下 Select * from 表名 where 欄位= 注入的參數為ID= And [查詢條件] 即是生成語句 Select * from 表名 where 欄位= And [查詢條件](B) Class=連續劇 這類注入的參數是字元型 SQL語句原貌大致概如下 Select * from 表名 where 欄位= 連續劇 注入的參數為Class=連續劇 and [查詢條件] and = 即是生成語句 Select * from 表名 where 欄位= 連續劇 and [查詢條件] and = (C) 搜索時沒過濾參數的 如keyword=關鍵字 SQL語句原貌大致如下 Select * from 表名 where 欄位like %關鍵字% 注入的參數為keyword= and [查詢條件] and % = 即是生成語句 Select * from 表名 where欄位like % and [查詢條件] and % = % 接著 將查詢條件替換成SQL語句 猜解表名 例如 ID= And (Select Count(*) from Admin)>= 如果頁面就與ID= 的相同 說明附加條件成立 即表Admin存在 反之 即不存在（請牢記這種方法） 如此循環 直至猜到表名為止 表名猜出來後 將Count(*)替換成Count(欄位名) 用同樣的原理猜解欄位名 有人會說 這里有一些偶然的成分 如果表名起得很復雜沒規律的 那根本就沒得玩下去了 說得很對 這世界根本就不存在 %成功的黑客技術 蒼蠅不叮無縫的蛋 無論多技術多高深的黑客 都是因為別人的程序寫得不嚴密或使用者保密意識不夠 才有得下手 有點跑題了 話說回來 對於SQLServer的庫 還是有辦法讓程序告訴我們表名及欄位名的 我們在高級篇中會做介紹 最後 在表名和列名猜解成功後 再使用SQL語句 得出欄位的值 下面介紹一種最常用的方法－Ascii逐字解碼法 雖然這種方法速度很慢 但肯定是可行的方法 我們舉個例子 已知表Admin中存在username欄位 首先 我們取第一條記錄 測試長度 ?id= and (select top len(username) from Admin)> 先說明原理 如果top 的username長度大於 則條件成立 接著就是> > > 這樣測試下去 一直到條件不成立為止 比如> 成立 > 不成立 就是len(username)= 當然沒人會笨得從 一個個測試 怎麼樣才比較快就看各自發揮了 在得到username的長度後 用mid(username N )截取第N位字元 再asc(mid(username N ))得到ASCII碼 比如 id= and (select top asc(mid(username )) from Admin)> 同樣也是用逐步縮小范圍的方法得到第 位字元的ASCII碼 注意的是英文和數字的ASCII碼在 之間 可以用折半法加速猜解 如果寫成程序測試 效率會有極大的提高 第二節 SQL注入常用函數 有SQL語言基礎的人 在SQL注入的時候成功率比不熟悉的人高很多 我們有必要提高一下自己的SQL水平 特別是一些常用的函數及命令 Access asc(字元)SQLServer unicode(字元)作用 返回某字元的ASCII碼Access chr(數字)SQLServer nchar(數字)作用 與asc相反 根據ASCII碼返回字元Access mid(字元串 N L)SQLServer substring(字元串 N L)作用 返回字元串從N個字元起長度為L的子字元串 即N到N+L之間的字元串Access abc(數字)SQLServer abc (數字)作用 返回數字的絕對值（在猜解漢字的時候會用到）Access A beeen B And CSQLServer A beeen B And C作用 判斷A是否界於B與C之間 第三節 中文處理方法 在注入中碰到中文字元是常有的事 有些人一碰到中文字元就想打退堂鼓了 其實只要對中文的編碼有所了解 中文恐懼症 很快可以克服 先說一點常識 Access中 中文的ASCII碼可能會出現負數 取出該負數後用abs()取絕對值 漢字字元不變 SQLServer中 中文的ASCII為正數 但由於是UNICODE的雙位編碼 不能用函數ascii()取得ASCII碼 必須用函數unicode ()返回unicode值 再用nchar函數取得對應的中文字元 了解了上面的兩點後 是不是覺得中文猜解其實也跟英文差不多呢？除了使用的函數要注意 猜解范圍大一點外 方法是沒什麼兩樣的 lishixin/Article/program/SQLServer/201311/22039

D. 什麼是sql注入，怎麼防止注入

sql注入其實就是在這些不安全控制項內輸入sql或其他資料庫的一些語句，從而達到欺騙伺服器執行惡意到嗎影響到資料庫的數據。防止sql注入，可以在接受不安全空間的內容時過濾掉接受字元串內的「'」，那麼他不再是一條sql語句，而是一個類似sql語句的zifuc，執行後也不會對資料庫有破壞。

如：

username = request("username") //獲取用戶名 這里是通過URL傳值獲取的。

password = request("password") //獲取密碼 也是通過URL傳值獲取的。

sql="select * from userlist where username = '" & username & "' and password = '" & password & "'"--------如果某個人知道某個用戶名是admin,常常有人網站的管理員用戶名就是admin,這是密碼可以選用'or 1 or ',

那麼sql="select * from userlist where username = 'admin' and password = '' or 1 or ''"，顯然1是恆真的，那麼驗證密碼就通過了。

防止的方式比較多，比如可以限制username,password中出現"'"這些字元，一般網站都是只允許數字，字元，下劃線的組合，這可以通過javascript驗證。也可以採取用存儲過程代替sql拼接，等等。

E. 求教高手------Asp。Net中如何防止SQL注入，即如何過濾關鍵字

最簡單的方法

你用ORM來做
就不存在SQL語句了

比如.net
3.5以後的linq
就是不錯的辦法

F. SQL注入 當or、and等常用字元被過濾(less-25)

當常用字元被注釋無法使用時，通常採取以下方法（可自行搜索sql注入繞開過濾等）：

如：Or、OR、oR等

如：通過hex、urlencode、url等編碼
舉例：如果or被過濾時，我們可以採用url編碼（其相當於把ascii編碼的0x給替換成%，比如o的ascii為0x6f，url編碼就是%6f），這個時候我們可以試試%6fr，即把o換成url編碼，也可以全換，也可以大小寫的換，如果沒被過濾就成功了，（如果%被過濾了的話…）
【註：這個可以積極的去使用，比如測試時and被注釋，使用&&替換也失敗，這個時候不妨試試%26%26（&的url編碼）】

如： /* */ （這個不止可以應對字母被注釋）
舉例：某個過濾器能夠過濾的字元如下——「select 」、」from 」、」limit 」等，注意這些字元最後面都有一個空格，這個時候我們就能通過內聯注釋來繞過這個過濾器，如：

【註：這個注釋甚至可以穿插在關鍵字當中，例如被過濾了or，我們可以把 order by 改成 o/**/rder by ，參考的資料上是這么說，但本人試了沒成功，不知是否依舊實用】

比如or被過濾了，我們可以往裡面加or，即注入：oorr，這個時候裡面的or就被刪去了，剩下的組成新字元，也就是or，是個很好用的繞過方法，像這種類似的還有很多，需要我們去思考

如：&&、||
舉例：

如盲注時經常用到比較，這時候要是比較符號被注釋了不能用平常的方法了，所以需要用某些函數如 greatest() 【 greatest(n1,n2,n3,...) 函數返回輸入參數(n1,n2,n3,...)的最大值】、least()等，比如語句： select * from users where id=1 and ascii(substr(database(),0,1))>64 就可以替換成 select * from users where id=1 and greatest(ascii(substr(database(),0,1)),64)=64
【註：當or被注釋時，像order by這種含有相關字元的語句也同樣無法使用，這個時候如果改變大小寫也無用時，可以使用上述的內聯注釋 /**/ ，或者用別的編碼形式，如果不行的話，那就只能放棄使用order by，可以嘗試使用group by語句等】

G. 【web安全】怎麼進行sql注入

1.POST注入，通用防注入一般限制get，但是有時候不限制post或者限制的很少，這時候你就可以試下post注入，比如登錄框、搜索框、投票框這類的。另外，在asp中post已被發揚光大，程序員喜歡用receive來接受數據，這就造成了很多時候get傳遞的參數通過post/cookie也能傳遞，這時如果恰好防注入程序只限制了get，因此post注入不解釋
2.cookie注入，原理同post注入，繞過相當多通用防注入
3.二次注入，第一次注入的數據可能不會有效，但是如果將來能在某個頁面裡面被程序處理呢?注入來了……
4.csrf，適合後台地址已知並且存在已知0day，可以試試用csrf劫持管理員來進行操作（這招其實不屬於sql注入了）
5.打碎關鍵字，比如過濾select，我可以用sel/**/ect來繞過，這招多見於mysql
6.有時候也可以sELeCT這樣大小寫混淆繞過
7.用chr對sql語句編碼進行繞過
8.如果等於號不好使，可以試試大於號或者小於號，如果and不好使可以試試or，這樣等價替換
9.多來幾個關鍵字確定是什麼防注入程序，直接猜測源碼或者根據報錯關鍵字（如"非法操作，ip地址已被記錄"）把源碼搞下來研究
10.記錄注入者ip和語句並寫入文件或資料庫，然而資料庫恰好是asp的，插馬秒殺

H. sql注入過程中單引號和多個關鍵字被過濾怎麼辦

很高興回答你的問題
SQL注入成功機率和選擇注入目標程序安全性有直接關系.單就你的問題和你的思路來說的話,你還可嘗試利用 ANSI 字元代碼變體來達到目的 比如 " 號對應 chr(34) .
是否成功取決於他本身程序是否也做了過濾.
另:還有很多方法同樣可以達到目的的.比如旁註、跨站、截取cookie 等

I. 如何對網站進行SQL注入

首先你要了解什麼是SQL注入漏洞，SQL注入漏洞就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令，比如很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到SQL注入式攻擊。
簡單來說，網站一般都是由web應用程序，資料庫，伺服器等組成的，網站的所有用戶數據，密碼表單等等都是保存在資料庫當中的，資料庫的內容按到常理來說是只能在伺服器內部進行查詢，當然，但是，開發人員對客戶端用戶向客戶端提交的參數沒有進行過濾，那麼，黑客就可以從客戶端【瀏覽器，等等，詳細可以學習http協議】向伺服器提交查詢資料庫的SQL語句，如果提交的語句成功的被伺服器給接收到並且執行么，那麼黑客豈不是想怎麼查詢資料庫裡面的內容就怎麼查詢，不是么？那些管理賬號密碼，會員數據不是分分鍾就到手了？SQL注入漏洞危害是非常大的。

當然，這種漏洞是根據提交參數沒過濾而產生的，那麼除了瀏覽器的get提交參數，http協議中還有，post提交，cookie提交，等等。注入漏洞不是網上那些所謂的黑闊，用什麼啊D，明小子之類的亂檢測一氣而找出來的，如果樓主想研究這個漏洞的產生，原理，利用和防禦，是需要進行代碼審計，SQL注入語句基礎，等等。

現在一般常用的工具：SQLmap【這是一款神器，現在是公認最強大的開源注入工具】

建議樓主去看幾本書：《SQL注入天書》《SQL注入漏洞的產生與防禦》

這個漏洞的利用不是幾句話就能說清楚的，詳細的可以追問，純手工打字，望樓主採納。

J. 如何關閉bootstrap里的sql注入過濾

1. 建議關閉或刪除不必要的互動式提交表單頁面，因為他們是黑客進行SQL注入的途徑，關閉這些互動式頁面可有效的阻止某些XSS跨站腳本的攻擊與注入。而最有效的防治注入及跨站腳本攻擊的方法，是在代碼層就屏蔽掉不安全的script等危險字元。
2.. 對漏洞注入點相關代碼進行代碼及SQL注入關鍵字的過濾，以規范代碼安全性。
3. 不要在伺服器端放置備份的文件以免受到感染，或備份的文件含有漏洞，造成切入點，比如index1.asp index2.asp procts1.asp等。