當前位置:首頁 » 編程語言 » sql注入測試
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sql注入測試

發布時間: 2022-02-22 03:51:31

⑴ web頁面怎樣做sql注入測試

直接在地址欄輸入表達式進行測試.
示例:www.xx。net?id=1'or'1'='1

⑵ 安全測試中sql的注入是什麼意思

所謂SQL注入,就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串,最終達到欺騙伺服器執行惡意的SQL命令。具體來說,它是利用現有應用程序,將(惡意)的SQL命令注入到後台資料庫引擎執行的能力,它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的資料庫,而不是按照設計者意圖去執行SQL語句。 比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的,這類表單特別容易受到SQL注入式攻擊.

一般來說要阻止sql注入,需要前後端配合表單的內容進行驗證。我是前端的,只要對表單的輸入綁定change事件,對其中的內容進行正則驗證,阻止用戶輸入特殊字元(比如\轉義字元)。

⑶ 如何測試一個網站是不是可以被SQL注入

SQL注入通過網頁對網站資料庫進行修改。它能夠直接在資料庫中添加具有管理員許可權的用戶,從而最終獲得系統管理員許可權。黑客可以利用獲得的管理員許可權任意獲得網站上的文件或者在網頁上加掛木馬和各種惡意程序,對網站和訪問該網站的網友都帶來巨大危害。

防禦SQL注入有妙法

第一步:很多新手從網上下載SQL通用防注入系統的程序,在需要防範注入的頁面頭部用來防止別人進行手動注入測試。

可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾,你的管理員賬號及密碼就會被分析出來。

第二步:對於注入分析器的防範,通過實驗,發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中,發現軟體並不是沖著「admin」管理員賬號去的,而是沖著許可權(如flag=1)去的。這樣一來,無論你的管理員賬號怎麼變都無法逃過檢測。

第三步:既然無法逃過檢測,那我們就做兩個賬號,一個是普通的管理員賬號,一個是防止注入的賬號,如果找一個許可權最大的賬號製造假象,吸引軟體的檢測,而這個賬號里的內容是大於千字以上的中文字元,就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。

1.對表結構進行修改。將管理員的賬號欄位的數據類型進行修改,文本型改成最大欄位255(其實也夠了,如果還想做得再大點,可以選擇備注型),密碼的欄位也進行相同設置。

2.對表進行修改。設置管理員許可權的賬號放在ID1,並輸入大量中文字元(最好大於100個字)。

3.把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。

我們通過上面的三步完成了對資料庫的修改。

另外要明白您做的ID1賬號其實也是真正有許可權的賬號,現在計算機處理速度那麼快,要是遇上個一定要將它算出來的軟體,這也是不安全的。只要在管理員登錄的頁面文件中寫入字元限制就行了,就算對方使用這個有上千字元的賬號密碼也會被擋住的,而真正的密碼則可以不受限制。

⑷ 如何檢測sql注入

不要拼接SQL語句,即防止傳入參數問題,
舉例:
select * from a where password = ' 變數 ';
假如傳入的變數是: ' or 1=1 or 1=',那麼最後這個語句就是:
select * from a where password = '' ' or 1=1 or 1='';
你說會得到什麼結果
如果你使用ADO,則盡量使用parameter方式傳入參數,不要自己拼接sql語句,要拼接的話,確保傳入參數不是可以破壞原sql語句的變數

⑸ 哪些工具可以用來測試sql注入漏洞

SQL注入漏洞有哪些 SQL注入攻擊是當今最危險、最普遍的基於Web的攻擊之一。所謂注入攻擊,是攻擊者把SQL命令插入到Web表單的輸入域頁面請求的查詢字元串中,如果要對一個網站進行SQL注入攻擊,首先需要找到存在SQL注入漏洞的地方

⑹ sql注入裡面的1=1 1=2測試法有什麼用

我覺得應該是 or 1=1 或者 and 1=2,or 1=1 表示條件一定會成立。 and 1=2表示條件一定不會成立。

比如一條語句 select password from users where username='xxx' or 1=1.

⑺ SQL注入求教學希望有網站可以測試

SQL注入是多少年前的 東西了。包括現在主流的IIS,Apache,Tomat 搭建的基礎環境 都可以在全局方面去防範SQL注入了。
如果你想測試 建議你去一些老的網站 asp 的 去嘗試。

⑻ SQL注入點檢測

WebCruiser - Web Vulnerability Scanner (Web應用漏洞掃描器)
WebCruiser - Web Vulnerability Scanner, a compact but powerful web security scanning tool! It has a Crawler and Vulnerability Scanner(SQL Injection, Cross Site Scripting, XPath Injection etc. ). It can support not only scanning website, but also Prooving of concept for web vulnerabilities: SQL Injection, Cross Site Scripting, XPath Injection etc. WebCruiser是一個小巧但功能不凡的Web應用漏洞掃描器,它能夠對整個網站進行漏洞掃描,並能夠對發現的漏洞(SQL注入,跨站腳本,XPath注入等)進行驗證;它也可以單獨進行漏洞驗證,作為SQL注入工具、XPath注入工具、跨站檢測工具使用。

功能簡介:
* 網站爬蟲(目錄及文件);
* 漏洞掃描(SQL注入,跨站腳本,XPath注入);
* 漏洞驗證(SQL注入,跨站腳本,XPath注入);
* SQL Server明文/欄位回顯/盲注;
* MySQL欄位回顯/盲注;
* Oracle欄位回顯/盲注;
* DB2欄位回顯/盲注;
* Access欄位回顯/盲注;
* 管理入口查找;
* GET/Post/Cookie 注入;
* 搜索型注入延時;
* 自動從自帶瀏覽器獲取Cookie進行認證;
* 自動判斷資料庫類型;
* 自動獲取關鍵詞;
* 多線程;
* 高級:代理、敏感詞替換/過濾;
* 報告;
---------------------------------------------------
Function:
* Crawler(Site Directories And Files);
* Vulnerability Scanner(SQL Injection, Cross Site Scripting, XPath Injection etc.);
* POC(Proof of Concept): SQL Injection, Cross Site Scripting, XPath Injection etc.;
* GET/Post/Cookie Injection;
* SQL Server: PlainText/FieldEcho(Union)/Blind Injection;
* MySQL/Oracle/DB2/Access: FieldEcho(Union)/Blind Injection;
* Administration Entrance Search;
* Time Delay For Search Injection;
* Auto Get Cookie From Web Browser For Authentication;
* Report Output.

⑼ 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;