① 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注入是一種非常常見的資料庫攻擊手段，同時也是網路世界中最普遍的漏洞之一，簡單理解就是惡意用戶通過在表單中填寫包含SQL關鍵字的數據來使資料庫執行非常規代碼的過程。
問題來源是，SQL資料庫的操作是通過SQL語句來執行的，而無論是執行代碼還是數據項都必須寫在SQL語句中，也就導致如果我們在數據項中加入了某些SQL語句關鍵字，比如SELECT、DROP等，這些關鍵字就很有可能在資料庫寫入或讀取數據時得到執行。
解決方案
方案一：
採用預編譯技術
使用預編譯的SQL語句，SQL語句的語義不會是不會發生改變的。預編譯語句在創建的時候就已經將指定的SQL語句發送給了DBMS，完成了解析，檢查，編譯等工作，所以攻擊者無法改變SQL語句的結構，只是把值賦給?，然後將?這個變數傳給SQL語句。當然還有一些通過預編譯繞過某些安全防護的操作，大家感興趣可以去搜索一下。
方案二：
嚴格控制數據類型
在java、c等強類型語言中一般是不存在數字型注入的，因為在接受到用戶輸入id時，代碼一般會做一個int id 的數據類型轉換，假如我們輸入的是字元串的話，那麼這種情況下，程序就會報錯。但是在PHP、ASP這些沒有強調處理數據類型的語言，一般我們看到的接收id的代碼都是如下等代碼。
方案三：
對特殊的字元進行轉義
數字型注入可以通過檢查數據類型防止，但是字元型不可以，那麼怎麼辦呢，最好的辦法就是對特殊的字元進行轉義了。比如在MySQL中我們可以對" '
"進行轉義，這樣就防止了一些惡意攻擊者來閉合語句。當然我們也可以通過一些安全函數來轉義特殊字元。如addslashes()等，但是這些函數並非一勞永逸，攻擊者還可以通過一些特殊的方式繞過。
③ 解決並清除SQL被注入
在SQL查詢分析器執行以下代碼就可以了。
declare
@t
varchar(255),@c
varchar(255)
declare
table_cursor
cursor
for
select
a.name,b.name
from
sysobjects
a,syscolumns
b
,systypes
c
where
a.id=b.id
and
a.xtype='u'
and
c.name
in
('char',
'nchar',
'nvarchar',
'varchar','text','ntext')
declare
@str
varchar(500),@str2
varchar(500)
set
@str='<script
src=http://r01.3322.org/c.js></script>'/*要替換的內容*/
set
@str2=''
open
table_cursor
fetch
next
from
table_cursor
into
@t,@c
while(@@fetch_status=0)
begin
exec('update
['
+
@t
+
']
set
['
+
@c
+
']=replace(cast(['
+
@c
+
']
as
varchar(8000)),'''+@str+''','''+
@str2
+''')')
fetch
next
from
table_cursor
into
@t,@c
end
close
table_cursor
deallocate
table_cursor;
首先替換代碼裡面的<script
src=http://r01.3322.org/c.js></script>為你的資料庫表裡面被注入的內容，打開MSSQL的SQL查詢分析器執行以下代碼就可以了。
④ 網站被sql注入了，怎麼辦
檢查一下鋒碰代碼里的sql，有往sql里傳值的仿仿地方都換成｛？｝，然後用preparedstatement做備基纖。
⑤ SQL注入的解決方式
對你的程序接收的各項參數進行非法字元過濾，確保你傳給sql伺服器的sql語句是正確的。
比如你要查詢 select * from news where id=100
那你就需要確保 id後面的內容一定是一個數字，而不會包含其他字元。如果含有其他字元你就將它強制變成數字1或者其他有效的ID值。
⑥ 如何防範SQL注入漏洞及檢測
以下是OMG我為大家收集整理的文章，希望對大家有所幫助。
SQL注入(SQLInjection)漏洞攻擊是目前網上最流行最熱門的黑客腳本攻擊方法之一，那什麼是SQL注入漏洞攻擊呢?它是指黑客利用一些Web應用程序(如：網站、論壇、留言本、文章發布系統等)中某些存在不安全代碼或SQL語句不縝密的頁面，精心構造SQL語句，把非法的SQL語句指令轉譯到系統實際SQL語句中並執行它，以獲取用戶名、口令等敏感信息，從而達到控制主機伺服器的攻擊方法。
1. SQL注入漏洞攻擊原理
1. 1 SQL注入漏洞攻擊實現原理
SQL(Structured Query Language)是一種用來和資料庫交互的語言文本。SQL注入的攻擊原理就是攻擊者通過Web應用程序利用SQL語句或字元串將非法的數據插入到伺服器端資料庫中，獲取資料庫的管理用戶許可權，然後將資料庫管理用戶許可權提升至操作系統管理用戶許可權，控制伺服器操作系統，獲取重要信息及機密文件。
SQL注入漏洞攻擊主要是通過藉助於HDSI、NBSI和Domain等SQL注入漏洞掃描工具掃描出Web頁面中存在的SQL注入漏洞，從而定位SQL注入點，通過執行非法的SQL語句或字元串達到入侵者想要的操作。下面以一段身份驗證的.NET代碼為例，說明一下SQL 注入攻擊的實現方法。
SqlConnectionnwConn = new SqlConnection((string)ConfigurationSettings.AppSettings["DBconnStrings"]); string queryStr = "SELECT userid,userpwd, username,type FROM users where userid='" + Txtusername.Text +"'";
DataSet userSet = new DataSet();
SqlDataAdapter userAdapter = newSqlDataAdapter(queryStr, nwConn);
userAdapter.Fill(userSet, "Users");
Session["UserID"] =Txtusername.Text.ToString();
Session["type"] =type.Text.ToString();
Response.Redirect("/Myweb/admin/login.aspx");
從上面的代碼中可以看出,程序在與資料庫建立連接得到用戶數據之後,直接將username的值通過session傳給login.aspx，沒有進行任何的過濾和處理措施, 直接用來構造SQL 語句, 其危險系數是非常高的, 攻擊者只要根據SQL 語句的編寫規則就可以繞過身份驗證，從而達到入侵的目的。
1. 2 SQL注入漏洞攻擊分析
SQL注入可以說是一種漏洞，也可以說是一種攻擊。當程序中的變數處理不當，沒有對用戶提交的數據類型進行校驗，編寫不安全的代碼，構造非法的SQL語句或字元串，都可能產生這個漏洞。
例如Web系統有一個login頁面，這個login頁面控制著用戶是否有權訪問，要求用戶輸入一個用戶名和口令，連接資料庫的語句為：
“select * from users where username = 'username' andpassword = 'password'”
攻擊者輸入用戶名為aa or 1=1口令為1234 or 1=1之類的內容。我們可以看出實際上攻擊者並不知道真正的用戶名、口令，該內容提交給伺服器之後，伺服器執行攻擊者構造出的SQL命令，但由於攻擊者輸入的內容非常特殊，所以最後得到的SQL命令變成：
“select * from users where username = 'aa' or 1=1 andpassword = '1234' or 1=1”
伺服器執行查詢或存儲過程，將用戶輸入的身份信息和資料庫users表中真實的身份信息進行核對，由於SQL命令實際上已被修改，存在永遠成立的1=1條件，因此已經不能真正驗證用戶身份，所以系統會錯誤地授權攻擊者訪問。
SQL 注入是通過目標伺服器的80埠進行的，是正常的Web訪問，防火牆不會對這種攻擊發出警告或攔截。當Web伺服器以普通用戶的身份訪問資料庫時，利用SQL注入漏洞就可能進行創建、刪除、修改資料庫中所有數據的非法操作。而當資料庫以管理用戶許可權的身份進行登錄時，就可能控制整個資料庫伺服器。
SQL注入的方法很多，在以手動方式進行攻擊時需要構造各種各樣的SQL語句，所以一般攻擊者需要豐富的經驗和耐心，才能繞過檢測和處理，提交語句，從而獲得想要的有用信息。這個過程需要花費很多的時間，如果以這種手動方式進行SQL注入漏洞攻擊，許多存在SQL注入漏洞的ASP、JSP、PHP、JAVA等網站就會安全很多了，不是漏洞不存在了，而是手動入侵者需要編程基礎，但現在攻擊者可以利用一些現成的黑客工具來輔助SQL注入漏洞攻擊，加快入侵的速度，使SQL注入變得輕而易舉。
由於SQL注入漏洞攻擊利用的是通用的SQL語法，使得這種攻擊具有廣泛性。理論上說，對於所有基於SQL語言的資料庫管理系統都是有效的，包括MSSQLServer、Oracle、DB2、Sybase和MySQL等。當然，各種系統自身的SQL擴展功能會有所不同，因此最終的攻擊代碼可能不盡相同。
1. 3 SQL注入漏洞攻擊過程
(1)繞過身份驗證
如一個login界面，需要輸入用戶名和口令，然後Post到另一個頁面，進行身份驗證,因此攻擊者只需在用戶名和口令的輸入框中都輸入aa or’1’=’1’的內容，那麼攻擊者就可以通過欺騙的驗證方式而直接進入下一個頁面，並擁有和正常登錄用戶一樣的全部特權。原因是什麼呢? 我們比較一下正常用戶登錄和攻擊者登錄時的兩種SQL語句：
1)正常用戶(如用戶名為admin，口令為1234567) ：
SQL= " selectfrom users where username = ’admin’and password= ’1234567’ ";
2)攻擊者(用戶名和口令都為aa or’1’=’1’) ：
SQL= " select * from users where username='aa or’1’=’1’'and password = ' aa or’1’=’1’'";
可以看到由and連接的兩個條件都被一個永遠成立的1=1所代替，執行的結果為true，資料庫會認為條件恆成立，會返回一個true，讓攻擊者以合法身份登錄進入下一個頁面。
(2)執行非法操作
如一個查詢頁面select1.asp? id=1，編程人員原本設計意圖是顯示id為1的查詢信息，而攻擊者利用程序中沒有對id內容進行檢查的機制，插入自己的代碼。
從select1.asp中摘錄一段關鍵代碼：
SQL= " select *from photo where photoid= 'id'";
可以看到，id沒有進行任何的處理，直接構成SQL語句並執行，而攻擊者在知道該系統資料庫中表名及欄位名的情況下，利用SQL語句特性(分號是將兩句SQL 語句分開的符號)，直接向資料庫Tuser表中添加記錄：
select1.asp? id= 1;Insertinto Tuser (username,password,type) values ('hack','1234567','管理員')，然後攻擊者就可以直接用hack進行登錄了。通過這樣的方法，攻擊者還可以對系統做任何的事情，包括添加、刪除、修改系統資源的操作。
(3)執行系統命令
如果Web主機使用MSSQL資料庫管理系統，那麼攻擊者就可以用到xp_cmdshell這個擴展存儲過程，xp_cmdshell是一個非常有用的擴展存儲過程，用於執行系統命令，比如dir、net等，攻擊者可以根據程序的不同，提交不同的語句：
execmaster.dbo.xp_cmdshell " dir "; exec master.dbo.xp_cmdshell" net user hack 1234567 /add ";
execmaster.dbo.xp_cmdshell " net localgroup administrators hack /add ";
這樣就可以向Web主機系統中成功添加了一個管理員帳戶。
2. SQL注入漏洞攻擊的檢測方式及方法
2. 1檢測方式
SQL注入漏洞攻擊檢測分為入侵前的檢測和入侵後的檢測。入侵前的檢測，可以通過手工方式，也可以使用SQL注入漏洞掃描工具軟體。檢測的目的是為預防SQL注入漏洞攻擊，而對於SQL注入漏洞攻擊後的檢測，主要是針對審計日誌的查看，SQL注入漏洞攻擊成功後，會在Web Service和資料庫的審計日誌中留下“痕跡”。
2. 2檢測方法
(1)動態SQL檢查
動態的SQL語句是一個進行資料庫查詢的強大的工具，但把它和用戶輸入混合在一起就使SQL注入成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入作為參數而不是命令來執行，這樣就限制了入侵者的行動。當然，它不適用於存儲過程中利用用戶輸入來生成SQL命令的情況。在這種情況下，用戶輸入的SQL命令仍可能得到執行，資料庫仍然存在SQL注入漏洞攻擊的危險。
(2)有效性校驗
如果一個輸入框只可能包括數字，那麼要通過驗證確保用戶輸入的都是數字。如果可以接受字母，檢查是不是存在不可接受的字元，那就需要設置字元串檢查功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。
(3)數據表檢查
使用SQL注入漏洞攻擊工具軟體進行SQL注入漏洞攻擊後，都會在資料庫中生成一些臨時表。通過查看資料庫中最近新建的表的結構和內容，可以判斷是否曾經發生過SQL注入漏洞攻擊。
(4)審計日誌檢查
在Web伺服器中如果啟用了審計日誌功能，則Web Service審計日誌會記錄訪問者的IP地址、訪問時間、訪問文件等信息，SQL注入漏洞攻擊往往會大量訪問某一個頁面文件(存在SQL注入點的動態網頁)，審計日誌文件會急劇增加，通過查看審計日誌文件的大小以及審計日誌文件中的內容，可以判斷是否發生過SQL注入漏洞攻擊事件;另外還可以通過查看資料庫審計日誌，查詢某個時間段是否有非法的插入、修改、刪除操作。
(5)其他
SQL注入漏洞攻擊成功後，入侵者往往會添加特權用戶(如：administrator、root、sa等)、開放非法的遠程服務以及安裝木馬後門程序等，可以通過查看用戶帳戶列表、遠程服務開啟情況、系統最近日期產生的一些文件等信息來判斷是否發生過入侵。
3. SQL注入漏洞防範措施
SQL注入漏洞攻擊的防範方法有很多種，現階段總結起來有以下方法：
(1)數據有效性校驗。如果一個輸入框只可能包括數字，那麼要通過校驗確保用戶輸入的都是數字。如果可以接受字母，那就要檢查是不是存在不可接受的字元，最好的方法是增加字元復雜度自動驗證功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。另外限製表單數據輸入和查詢字元串輸入的長度也是一個好方法。如果用戶的登錄名最多隻有10個字元，那麼不要認可表單中輸入10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
(2)封裝數據信息。對客戶端提交的數據進行封裝，不要將數據直接存入cookie中，方法就是在編程的代碼中，插入session、if、try、else，這樣可以有效地防止攻擊者獲取cookie中的重要信息。
(3)去除代碼中的敏感信息。將在代碼中存在的用戶名、口令信息等敏感欄位刪除，替換成輸入框。
SQL=" select from users where username = ’admin’and password= ’1234567’ "
如：這樣顯然會暴露管理員的用戶名、口令信息。可以將其修改成：
SQL= " select * from users where username='" +Txtuser.Text + "' and userpwd='" + Textpwd.Text + "'"
這樣就安全了很多，入侵者也是不會輕易的就獲取到用戶名、口令信息。
(4)替換或刪除單引號。使用雙引號替換掉所有用戶輸入的單引號，這個簡單的預防措施將在很大程度上預防SQL注入漏洞攻擊，單引號時常會無法約束插入數據的Value，可能給予輸入者不必要的許可權。用雙引號替換掉單引號可以使大部分SQL注入漏洞攻擊失敗。 如：
“select* from users where username='" + admin + "' and userpwd='" + 1234567+ "'”
顯然會得到與
“select * from users where username='admin' and password= '1234567'”
相同的結果。
(5)指定錯誤返回頁面。攻擊者有時從客戶端嘗試提交有害代碼和攻擊字元串，根據Web Service給出的錯誤提示信息來收集程序及伺服器的信息，從而獲取想得到的資料。應在Web Service中指定一個不包含任何信息的錯誤提示頁面。
(6)限制SQL字元串連接的配置文件。使用SQL變數，因為變數不是可以執行的腳本，即在Web頁面中將連接資料庫的SQL字元串替換成指定的Value，然後將Web.config文件進行加密，拒絕訪問。
(7)設置Web目錄的訪問許可權。將虛擬站點的文件目錄禁止遊客用戶(如：Guest用戶等)訪問，將User用戶許可權修改成只讀許可權，切勿將管理許可權的用戶添加到訪問列表。
(8)最小服務原則。Web伺服器應以最小許可權進行配置，只提供Web服務，這樣可以有效地阻止系統的危險命令，如ftp、cmd、vbscript等。
(9)鑒別信息加密存儲。將保存在資料庫users表中的用戶名、口令信息以密文形式保存，也可以對users表進行加密處理，這樣可以大大增加對鑒別信息訪問的安全級別。
(10)用戶許可權分離。應盡可能的禁止或刪除資料庫中sa許可權用戶的訪問，對不同的資料庫劃分不同的用戶許可權，這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作，就可以防止不同用戶對非授權的資料庫進行訪問。
4. 結束語
SQL注入漏洞攻擊在網上非常普遍，許多ASP、PHP論壇和文章管理系統、下載系統以及新聞系統都存在這個漏洞。造成SQL注入漏洞攻擊的主要原因是開發人員在系統開發的過程中編程不規范，沒有形成良好的編程習慣，問題的解決只有依賴於規范編程。此外，也可以使用現有的SQL注入漏洞掃描器對整個網站中的關鍵代碼進行掃描，查找網站頁面中存在的SQL注入點。對於有問題的頁面，可以及時刪除或更新。本文通過對SQL注入漏洞攻擊的方法、原理以及攻擊實施過程進行了闡述和總結，並給出了一些常見的SQL注入漏洞攻擊防範的方法。
⑦ 網站資料庫被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注入其實不難，你知道原理就可以了。
1、所有的sql注入都是從用戶的輸入開始的。如果你對所有用戶輸入進行了判定和過濾，就可以防止sql注入了。用戶輸入有好幾種，我就說說常見的吧。
2、文本框、地址欄里***.asp?中？號後面的id=1之類的、單選框等等。一般sql注入都用地址欄里的。。。。
3、對於所有從上一頁傳遞過來的參數，包括request.form
、request.qurrystring等等進行過濾和修改。如最常的***.asp?id=123
，我們的id只是用來對應從select
里的id，而這id一般對應的是一個數據項的唯一值，而且是數字型的。這樣，我們只需把id的值進行判定，就可以了。
⑨ 如何修復SQL注入漏洞
以下是OMG我為大家收集整理的文章，希望對大家有所幫助。
SQL注入是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。其實就是就是提交精心構造的資料庫語句，使其反饋一些有用的數據。說白了就是去欺騙資料庫，假如只有web伺服器的話，是沒法進行SQL注入的。
網上常用的注入手法有兩種，一種是猜測，讓資料庫暴出用戶名、密碼等信息;另一種直接繞過認證，取得許可權。相對應，要想修復此類漏洞，就必須禁止特殊數據的提交或將特殊提交的數據修改。
下面是不同腳本語言下的防注入過濾代碼，其實思想是一致的。
1、 PHP防注入過濾代碼
php 代碼復制內容到剪貼板
<!-- ?php
/*************************
說明： 判斷傳遞的變數中是否含有非法字元 如$_POST、$_GET
功能： 防注入
使用方法： 將下列代碼保存為ak,php,調用方式 在數據提交頁加上include("ak.php");
**************************/
function dowith_sql($str)
//實現將特徵碼兩邊加.
{
$refuse_str="exec|and|or|select|update|from|where|order|by|*|delete||insert|into|values|create|table|
database|set|char|asc|cast|declare| </script|script|iframe|3bomb|c.js|;";>
//定義防注入的字元
$arr=explode("|",$refuse_str);
//將$refuse_str中的值單獨取出
for($i=0;$i<count($arr);$i++) p=""> </count($arr);$i++)>
{
$replace="[".$arr[$i]."]";
$str=str_replace($arr[$i],$replace,$str);
//在變數$str中搜索字元串$arr[$i]，並將其替換為字元串[$replace]
}
return $str;
}
foreach ($_GET as $key=>$value)
//遍歷獲GET方法獲得的參數$_GET的值傳給$key,並賦值給$value
{
$_GET[$key]=dowith_sql($value);
//將$value中的特徵碼處理傳個$_GET[$key]
}
foreach ($_POST as $key=>$value)
{
$_POST[$key]=dowith_sql($value);
}
?>
上面的防注入的方法只是防了GET與POST方法提交的數據，但是，WEB伺服器讀取數據的順序是，先取GET中的數據，沒有再去POST中的數據，沒有還會再去COOKIES中的數據，上面的代碼還沒有防cookies注入。防cookies注入就比較簡單了，cookies的id值一般只為阿拉伯數字，但是cookies注入必須得在id中構造代碼，只要在獲得參數UID後，對其進行過濾就可以了，代碼如下：
php 代碼復制內容到剪貼板
<!-- ?php
if($_COOKIE[id]!=null) {
//判斷cookies不為空
foreach ($_COOKIE[id] as $key=>$id){
//讀取cookies中的值
if (is_numeric($id)<0){
echo " ";
}
}
｝
?>
將上述代碼保存為hk.php。
所以在平時應用時，在網頁上加上include("ak.php");與include("hk.php");
2、 ASP防注入過濾代碼
<%
--------說明------------------
使用方法： 在需要防注的頁面頭部用 SSI ʱ B>
包含就可以了
友情提示：把代碼復制到CONN.asp(資料庫連接文件) 那麼，只要包含了CONN的所有文件都防注了
-------- ------------------------
Dim xf_Post,xf_Get,xf_In,xf_Inf,xf_Xh,xf_db,xf_dbstr
自定義需要過濾的字串,用 "|" 分隔
xf_In = "|;|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare"
xf_Inf = split(xf_In,"|")
If Request.Form<>"" Then
For Each xf_Post In Request.Form
For xf_Xh=0 To Ubound(xf_Inf)
If Instr(LCase(Request.Form(xf_Post)),xf_Inf(xf_Xh))<>0 Then
Response.Write ""
Response.Write "非法操作!系統做了如下記錄↓
"
Response.Write "操作IP："&Request.ServerVariables("REMOTE_ADDR")&"
"
Response.Write "操作時間："&Now&"
"
Response.Write "操作頁面："&Request.ServerVariables("URL")&"
"
Response.Write "提交方式：POST
"
Response.Write "提交參數："&xf_Post&"
"
Response.Write "提交數據："&Request.Form(xf_Post)
Response.End
End If
Next
Next
End If
If Request.QueryString<>"" Then
For Each xf_Get In Request.QueryString
For xf_Xh=0 To Ubound(xf_Inf)
If Instr(LCase(Request.QueryString(xf_Get)),xf_Inf(xf_Xh))<>0 Then
Response.Write ""
Response.Write "非法操作!系統已經給你做了如下記錄↓
"
Response.Write "操作IP："&Request.ServerVariables("REMOTE_ADDR")&"
"
Response.Write "操作時間："&Now&"
"
Response.Write "操作頁面："&Request.ServerVariables("URL")&"
"
Response.Write "提交方式：GET
"
Response.Write "提交參數："&xf_Get&"
"
Response.Write "提交數據："&Request.QueryString(xf_Get)
Response.End
End If
Next
Next
End If
%>
同樣，再將cookies防一下，代碼加在數據提交頁。
if(Request.Cookies["uid"]!=null)
{
uid=Request.Cookies["uid"].value;
isnumeric cooidesID = new isnumeric();
//這是一個類
if (cooidesID.reIsnumeric(ruid))
//如果是數字就運行下面的
{
string str="select * from userTable where id="+uid;
...
}
}
3、 JSP防注入過濾代碼
⑩ 如何解決報表的 SQL 植入風險
SQL 注入或者 SQL 植入是 WEB 應用程序與資料庫交互過程中，由於對用戶輸入數據的合法性、規范性檢測做的不嚴而導致的一種常見的漏洞，這種漏洞如果被攻擊者加以利用，在查詢語句的結尾添加非法的 SQL 語句，就能進行非法的查詢，會導致數據泄露，風險很大
報表應用作為一個 WEB 應用，同樣會面臨這樣的風險
為了解決普通參數查詢不靈活，不自由的問題，很多報表工具開放了動態拼 SQL 的功能，允許 SQL 中進行子句替換，類似這樣:
SELECT … FROM T WHERE ${w}
w 就是可以根據用戶需求隨意拼的，比如 data>… AND date<=… AND area=…
這樣查詢就靈活多了，但是風險也就來了，這個 w 就會有 SQL 注入的隱患，比如：
SELECT … FROM T WHERE 1=0 UNION SELECT … FROM user
這是一句可執行的合法 SQL，但 user 表中的信息就被泄露了
怎麼樣解決這個問題呢？
1 盡量使用普通的 SQL 參數，不要動態拼 SQL
這樣做，雖然靈活度差一點，但安全
有些報表工具不支持普通 SQL 參數，只提供拼 SQL 的方案，方便是方便了，但就要小心了
2 需要通用查詢時，寫復雜一點的 SQL
比如：
SELECT … FROM T WHERE (${w})
SELECT … FROM T WHERE (${w}) OR ${w}
這樣做有一定的效果，但是並不完美，有些時候也防不住，而且 SQL 復雜後，會影響執行效率
3 再檢查關鍵字
通常通用查詢的條件不會有這些 select,from 等關鍵字，所以可以通過過濾這些關鍵字來防範風險，不讓參數中有這些關鍵字的 SQL 執行，雖然這樣做有時候會失去一些靈活性，但是安全性卻更高了
潤乾報表把這些都做好了，直接用就可以了
我們就以潤乾報表為例，來簡單看一下實現步驟
部署潤乾報表後，在應用目錄下找到 **raqsoftConfig.xml ** 文件，配置敏感詞列表
屬性名：disallowedParamWordList，value 為禁用敏感詞列表，多個之間用逗號分隔，英文字母不區分大小寫
配置列表以後，如果訪問的 URL 中再出現敏感詞，就會提示出錯了，減少風險的發生
http://localhost:6868/demo/reportJsp/showReport.jsp?rpx=a.rpx&arg2= 華北 union select * from users
是的就這么簡單，在一個已經提供了防止 SQL 注入的工具中，就是這么輕松一步設置就可以規避風險了，所以選型的時候，多問問，看看各廠商是否能解決這問題，怎麼解決的，否則就得自己去費勁去修補這個漏洞了
更詳細的操作以及其他解決方式請參考： 報表的 SQL 植入風險及規避方法 - 乾學院