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

sql注入網站攻擊流程圖

發布時間: 2022-04-13 12:01:40

❶ 如何實施sql注入攻擊

如何實施SQL注入攻擊
比如輸入框:你輸入單引號 『你好'or 1=1' 來破壞查詢資料庫的SQL執行
一般成熟的網站都會對SQL進行屏蔽,對特殊符號進行轉換等,比如MYBATIS就可以自動替換等,一般不會成功。

❷ 求教誰給講講SQL注入攻擊的步驟

第一步:SQL注入點探測。探測SQL注入點是關鍵的第一步,通過適當的分析應用程序,可以判斷什麼地方存在SQL注入點。通常只要帶有輸入提交的動態網頁,並且動態網頁訪問資料庫,就可能存在SQL注入漏洞。如果程序員信息安全意識不強,採用動態構造SQL語句訪問資料庫,並且對用戶輸入未進行有效驗證,則存在SQL注入漏洞的可能性很大。一般通過頁面的報錯信息來確定是否存在SQL注入漏洞。
第二步:收集後台資料庫信息。不同資料庫的注入方法、函數都不盡相同,因此在注入之前,我們先要判斷一下資料庫的類型。判斷資料庫類型的方法有很多,可以輸入特殊字元,如單引號,讓程序返回錯誤信息,我們根據錯誤信息提示進行判斷,還可以使用特定函數來判斷。
第三步:猜解用戶名和密碼。資料庫中的表和欄位命名一般都是有規律的,通過構造特殊的SQL語句在資料庫中依次猜解出表名、欄位名、欄位數、用戶名和密碼。
第四步:查找Web後台管理入口。Web後台管理通常不對普通用戶開放,要找到後台管理的登錄網址,可以利用Web目錄掃描工具快速搜索到可能的登錄地址,然後逐一嘗試,便可以找到後台管理平台的登錄網址。
第五步:入侵和破壞。一般後台管理具有較高許可權和較多的功能,使用前面已破譯的用戶名、密碼成功登錄後台管理平台後,就可以任意進行破壞,比如上傳木馬、篡改網頁、修改和竊取信息等,還可以進一步提權,入侵Web伺服器和資料庫伺服器。

❸ 製作網站時,SQL注入是什麼怎麼注入法

SQL注入是:

許多網站程序在編寫時,沒有對用戶輸入數據的合法性進行判斷,使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼(一般是在瀏覽器地址欄進行,通過正常的www埠訪問),根據程序返回的結果,獲得某些想得知的數據,這就是所謂的SQL Injection,即SQL注入。

網站的惡夢——SQL注入

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

防禦SQL注入有妙法

第一步:很多新手從網上下載SQL通用防注入系統的程序,在需要防範注入的頁面頭部用 來防止別人進行手動注入測試。可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾,你的管理員賬號及密碼就會被分析出來。

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

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

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

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

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

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

這時是不是修改結束了呢?其實不然,要明白你做的ID1賬號其實也是真正有許可權的賬號,現在計算機處理速度那麼快,要是遇上個一定要將它算出來的軟體,這也是不安全的。我想這時大多數人已經想到了辦法,對,只要在管理員登錄的頁面文件中寫入字元限制就行了!就算對方使用這個有上千字元的賬號密碼也會被擋住的,而真正的密碼則可以不受限制。

❹ 如何利用sql注入攻擊刪除文件

一、 SQL注入攻擊的簡單示例。
statement := "SELECT * FROM Users WHERE Value= " + a_variable + "
上面這條語句是很普通的一條SQL語句,他主要實現的功能就是讓用戶輸入一個員工編號然後查詢處這個員工的信息。但是若這條語句被不法攻擊者改裝過後,就可能成為破壞數據的黑手。如攻擊者在輸入變數的時候,輸入以下內容SA001』;drop table c_order--。那麼以上這條SQL語句在執行的時候就變為了SELECT * FROM Users WHERE Value= 『SA001』;drop table c_order--。
這條語句是什麼意思呢?『SA001』後面的分號表示一個查詢的結束和另一條語句的開始。c_order後面的雙連字元 指示當前行餘下的部分只是一個注釋,應該忽略。如果修改後的代碼語法正確,則伺服器將執行該代碼。系統在處理這條語句時,將首先執行查詢語句,查到用戶編號為SA001 的用戶信息。然後,數據將刪除表C_ORDER(如果沒有其他主鍵等相關約束,則刪除操作就會成功)。只要注入的SQL代碼語法正確,便無法採用編程方式來檢測篡改。因此,必須驗證所有用戶輸入,並仔細檢查在您所用的伺服器中執行構造 SQL命令的代碼。
二、 SQL注入攻擊原理。
可見SQL注入攻擊的危害性很大。在講解其防止辦法之前,資料庫管理員有必要先了解一下其攻擊的原理。這有利於管理員採取有針對性的防治措施。
SQL注入是目前比較常見的針對資料庫的一種攻擊方式。在這種攻擊方式中,攻擊者會將一些惡意代碼插入到字元串中。然後會通過各種手段將該字元串傳遞到SQLServer資料庫的實例中進行分析和執行。只要這個惡意代碼符合SQL語句的規則,則在代碼編譯與執行的時候,就不會被系統所發現。
SQL注入式攻擊的主要形式有兩種。一是直接將代碼插入到與SQL命令串聯在一起並使得其以執行的用戶輸入變數。上面筆者舉的例子就是採用了這種方法。由於其直接與SQL語句捆綁,故也被稱為直接注入式攻擊法。二是一種間接的攻擊方法,它將惡意代碼注入要在表中存儲或者作為原書據存儲的字元串。在存儲的字元串中會連接到一個動態的SQL命令中,以執行一些惡意的SQL代碼。
注入過程的工作方式是提前終止文本字元串,然後追加一個新的命令。如以直接注入式攻擊為例。就是在用戶輸入變數的時候,先用一個分號結束當前的語句。然後再插入一個惡意SQL語句即可。由於插入的命令可能在執行前追加其他字元串,因此攻擊者常常用注釋標記「—」來終止注入的字元串。執行時,系統會認為此後語句位注釋,故後續的文本將被忽略,不背編譯與執行。
三、 SQL注入式攻擊的防治。
既然SQL注入式攻擊的危害這么大,那麼該如何來防治呢?下面這些建議或許對資料庫管理員防治SQL注入式攻擊有一定的幫助。
1、 普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句,那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象,故要操作這個語句用戶必須有相關的許可權。在許可權設計中,對於終端用戶,即應用軟體的使用者,沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼,由於其用戶許可權的限制,這些代碼也將無法被執行。故應用程序在設計的時候,最好把系統管理員的用戶與普通用戶區分開來。如此可以最大限度的減少注入式攻擊對資料庫帶來的危害。
2、 強迫使用參數化語句。
如果在編寫SQL語句的時候,用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話,那麼就可以有效的防治SQL注入式攻擊。也就是說,用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反,用戶的輸入的內容必須進行過濾,或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施,可以杜絕大部分的SQL注入式攻擊。不過可惜的是,現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。
3、 加強對用戶輸入的驗證。
總體來說,防治SQL注入式攻擊可以採用兩種方法,一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中,有比較多的用戶輸入內容驗證工具,可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容,只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入,防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型,強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出,對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾,如拒絕一些特殊的符號。如以上那個惡意代碼中,只要存儲過程把那個分號過濾掉,那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前,可以通過資料庫的存儲過程,來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下,應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符,它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容,故可以直接把他拒絕掉,通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉,那麼即使在SQL語句中嵌入了惡意代碼,他們也將毫無作為。
故始終通過測試類型、長度、格式和范圍來驗證用戶輸入,過濾用戶輸入的內容。這是防止SQL注入式攻擊的常見並且行之有效的措施。
4、 多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響,在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中,工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話,則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼,則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查,范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束,就會發生異常,並報告給管理員。如上面這個案例中,如果員工編號定義的數據類型為字元串型,長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據,但是其長度達到了20個字元。則此時就會引發異常,因為用戶輸入的內容長度超過了資料庫欄位長度的限制。
5、 多層環境如何防治SQL注入式攻擊?
在多層應用環境中,用戶輸入的所有數據都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的數據應被資料庫拒絕,並向上一層返回一個錯誤信息。實現多層驗證。對無目的的惡意用戶採取的預防措施,對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程序中驗證數據可以防止簡單的腳本注入。但是,如果下一層認為其輸入已通過驗證,則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。故對於多層應用環境,在防止注入式攻擊的時候,需要各層一起努力,在客戶端與資料庫端都要採用相應的措施來防治SQL語句的注入式攻擊。
6、 必要的情況下使用專業的漏洞掃描工具來尋找可能被攻擊的點。
使用專業的漏洞掃描工具,可以幫助管理員來尋找可能被SQL注入式攻擊的點。不過漏洞掃描工具只能發現攻擊點,而不能夠主動起到防禦SQL注入攻擊的作用。當然這個工具也經常被攻擊者拿來使用。如攻擊者可以利用這個工具自動搜索攻擊目標並實施攻擊。為此在必要的情況下,企業應當投資於一些專業的漏洞掃描工具。一個完善的漏洞掃描程序不同於網路掃描程序,它專門查找資料庫中的SQL注入式漏洞。最新的漏洞掃描程序可以查找最新發現的漏洞。所以憑借專業的工具,可以幫助管理員發現SQL注入式漏洞,並提醒管理員採取積極的措施來預防SQL注入式攻擊。如果攻擊者能夠發現的SQL注入式漏洞資料庫管理員都發現了並採取了積極的措施堵住漏洞,那麼攻擊者也就無從下手了。

如何防範黑客入侵網站的幾種常見安全方法
• 本文的目的是告訴企業在建網站時如何打造一個防範黑客攻擊的安全網站
• 互聯網隨著時間的發展,它的優勢越來越來明顯,世界越來越多的企業通過這二十四小時不間斷的傳波平台,打造自己公司的網站,開展電子商務活動;由於互聯網的特殊性和復雜性,一旦你企業的網站接入互聯網後,你的企業網站便為一個公眾場所,任何人都可以上你的企業網站瀏覽信息,任何人(比如:黑客)都有可能對你的企業網站進行技術上測試,查找你的企業網站在程序設計上的漏洞,不論他目的是惡意還其它原因,你都無法制止他的行為,因為黑客在遠程電腦上實施操作。
• 建設一個有安全系數保證的網站,關系著一個企業的商業信譽問題,面臨日夜猖狂、日益肆虐的網路攻擊事件不斷發生,給自己的網站做一些最基本的安全防範措施是非常必要的。
• 非法字元過濾和轉換
• 黑客攻擊網站之前,先採用探路方式,通過網站的留言、論壇、搜索等系統,注入可執行的web腳本代碼和SQL語法,來達到入侵網站的目的;對網站所有互動式介面的文本輸入框(如:網站留言系統、BBS系統、blog系統、搜索系統、登陸系統等)的地方採取在客戶端非法字元過濾和轉換技術,通過非法字元過濾和轉換將可執行的惡意代碼變為可讀HTML代碼,使它基本失去了暴破網站的威力,又起到了保護網站程序源代碼不受破壞的作用。
• 建一個指定自定義出錯(Error)的信息頁面
• 好處在於防止網站設計源代碼的溢出,黑客在入侵網站的後台管理系統,往往在網頁地址欄輸入可執行的SQL語法和根據程序員為網頁命名的習慣輸入網址的文件名,一旦黑客採用這種方式,就會將黑客帶向指定自定義出錯(Error)的信息頁面。

• 拒絕Cookie驗證方式
• Cookie的好處在於管理員和注冊用戶登陸網站時Cookie會保存登陸信息,下次再登陸時Cookie會自動將這些信息保留在登陸的頁面輸入文本框中,其作用是為了方便登陸者,但也給黑客採集Cookie的信息提供了良機,所以應該拒絕採用客戶端Cookie驗證登陸方式,而改用通過伺服器驗證方式登陸並對賬號和密碼採用單向加密方式保存。
• 不要用自助建網站系統建你的企業網站
• 一些網站設計公司為了增加銷量降低成本(其實大部分客戶喜歡購買廉價的自助建網站系統),開發不同用途的自助建網站系統(如:網站內容管理、BBS、新聞發布、留言、博客等),同時為了爭奪市場、擴大產品知名度,往往兩種方式銷售產品:個人版可以免費下載;商業版則需要購買;其實兩個版本的網站在是同一種程序技術基礎開發出來的,商業版是授權驗證後可作商業用途,有技術支持和維護保證;黑客通過下載個人版,來潛心深研這些自助建網站系統的開放源代碼,從中找出程序漏洞,一旦發現了可攻擊的程序漏洞,通過搜索引擎平台檢索出同一型號版本自建網站系統,然後就發起攻擊;解決方式找有自主能力開發網站公司設計你的企業網站,通過將網站的設計源代碼封裝成「.dll」組件,這樣即保證網站設計上的安全性又保護了源代碼,又提高了網站的安全系數同時也降低了網站被入侵的危害程度,因為黑客攻陷網站往往是從研究網站源代碼開始並中找出程序漏洞。
• 解決Googel「暴庫」問題
• 一些程序員在開發網站喜歡用虛擬路徑方法調用資料庫,這就必須將資料庫保存在開通WWW服務的文件夾下,自然逃不過狡猾黑客的眼睛,一旦黑客破解了資料庫的真實保存位置,便可以從瀏覽器的地址欄打開和下載該資料庫,對網站的後果是非常危險的;要想確保你網站的資料庫不被黑客下載,只要採取將資料庫保存在非WWW服務的文件夾下,通過物理(真實)路徑方法調用資料庫,就可完全防止黑客下載你企業網站的資料庫。

• 建立robots文件
• 為了防止網站的重要文件夾(如:後台管理)和文件(如:純程序文件)不被搜索引擎所收錄,首先在網站根目錄下建一個「robots.txt」純文本文件,來防止網站的重要文件或其它敏感信息被搜索引擎所收錄;最大多搜索引擎平台都遵守robots協議;搜索引擎機器人訪問網站時,首先找到網站根目錄下robots文件,然後會讀取robots文件的內容,來確定它對網站收錄的范圍;robots文件可以說是對搜索引擎機器人收錄許可權的限制管理,從而避免將網站的重要文件或其它敏感信息暴露在網路上,在網站安全上起一個防禦鎖作用,robots文件可由網站設計者在遵守robots協議下,根據網站的實際情況自由編寫。
• 完全將杜絕黑客的攻擊和入侵是不可能的,完全在網站的每個介面過濾和轉換非法字元串是辦不到,比如,在文件上傳時,狡猾黑客會採取躲過過濾和轉換非法字元串的辦法,將可執行惡意腳本代碼保存「.gif」格式或「.jpg」格式來實施文件上傳漏洞攻擊,解決的方法是對所有上傳的文件先導入到「.txt」純文本文件讀一遍,判斷是否是可執行惡意腳本代碼,如果是就刪除,但是網站管理員要有web程序基礎;黑客入侵網站的方式變化多端,幾千種免費暴破網站的軟體,使你企業網站防不勝防,但是以上介紹幾種防禦措施對菜鳥黑客是可行的,對於一些資深黑客,他也要費一些精力和時間來暴破你企業網站,他會考慮值不值得?畢竟你的網站只是一個企業網站,不是銀行和證券交涉現金交易的網站(它們的程序設計安全系數更高),在大多數下情況,「大俠」黑客不會光顧你企業網站。

1、SQL注入漏洞的入侵
這種是ASP+ACCESS的網站入侵方式,通過注入點列出資料庫裡面管理員的帳號和密碼信息,然後猜解出網站的後台地址,然後用帳號和密碼登錄進去找到文件上傳的地方,把ASP木馬上傳上去,獲得一個網站的WEBSHELL。這個是黑鏈使用的前一部分,應該比較常用吧。現在網上賣webshell的太多了。
2、ASP上傳漏洞的利用
這種技術方式是利用一些網站的ASP上傳功能來上傳ASP木馬的一種入侵方式,不少網站都限制了上傳文件的類型,一般來說ASP為後綴的文件都不允許上傳,但是這種限制是可以被黑客突破的,黑客可以採取COOKIE欺騙的方式來上傳ASP木馬,獲得網站的WEBSHELL許可權。
3、後台資料庫備份方式獲得WEBSHELL
這個主要是利用網站後台對ACCESS資料庫進行資料庫備份和恢復的功能,備份資料庫路徑等變數沒有過濾導致可以把任何文件的後綴改成ASP,那麼利用網站上傳的功能上傳一個文件名改成JPG或者GIF後綴的ASP木馬,然後用這個恢復庫備份和恢復的功能把這個木馬恢復成ASP文件,從而達到能夠獲取網站WEBSHELL控制許可權的目的。
4、網站旁註入侵
這種技術是通過IP綁定域名查詢的功能查出伺服器上有多少網站,然後通過一些薄弱的網站實施入侵,拿到許可權之後轉而控制伺服器的其它網站。
下面這幾種我就聽不懂了,不過有點高技術的站長會看懂的。
5、sa注入點利用的入侵技術
這種是ASP+MSSQL網站的入侵方式,找到有SA許可權的SQL注入點,然後用SQL資料庫的XP_CMDSHELL的存儲擴展來運行系統命令建立系統級別的帳號,然後通過3389登錄進去,或者在一台肉雞上用NC開設一個監聽埠,然後用VBS一句話木馬下載一個NC到伺服器裡面,接著運行NC的反向連接命令,讓伺服器反向連接到遠程肉雞上,這樣遠程肉雞就有了一個遠程的系統管理員級別的控制許可權。
6、sa弱密碼的入侵技術
這種方式是用掃描器探測SQL的帳號和密碼信息的方式拿到SA的密碼,然後用SQLEXEC之類的工具通過1433埠連接到遠程伺服器上,然後開設系統帳號,通過3389登錄。然後這種入侵方式還可以配合WEBSHELL來使用,一般的ASP+MSSQL 網站通常會把MSSQL的連接密碼寫到一個配置文件當中,這個可以用WEBSHELL來讀取配置文件裡面的SA密碼,然後可以上傳一個SQL木馬的方式來獲取系統的控制許可權。
7、提交一句話木馬的入侵方式
這種技術方式是對一些資料庫地址被改成asp文件的網站來實施入侵的。黑客通過網站的留言版,論壇系統等功能提交一句話木馬到資料庫裡面,然後在木馬客戶端裡面輸入這個網站的資料庫地址並提交,就可以把一個ASP木馬寫入到網站裡面,獲取網站的WEBSHELL許可權。
8、論壇漏洞利用入侵方式
這種技術是利用一些論壇存在的安全漏洞來上傳ASP木馬獲得WEBSHELL許可權,最典型的就是,動網6.0版本,7.0版本都存在安全漏洞,拿7.0版本來說,注冊一個正常的用戶,然後用抓包工具抓取用戶提交一個ASP文件的COOKIE,然後用明小子之類的軟體採取COOKIE欺騙的上傳方式就可以上傳一個ASP木馬,獲得網站的WEBSHELL。

❺ 如何檢測SQL注入技術以及跨站腳本攻擊

在最近兩年中,安全專家應該對網路應用層的攻擊更加重視。因為無論你有多強壯的防火牆規則設置或者非常勤於補漏的修補機制,如果你的網路應用程序開發者沒
有遵循
安全代碼進行開發,攻擊者將通過80埠進入你的系統。廣泛被使用的兩個主要攻擊技術是SQL注入[ref1]和CSS[ref2]攻擊。SQL注入是
指:通過互聯網的輸入區域,插入SQL meta-characters(特殊字元
代表一些數據)和指令,操縱執行後端的SQL查詢的技術。這些攻擊主要針對其他組織的WEB伺服器。CSS攻擊通過在URL里插入script標簽,然後

誘導信任它們的用戶點擊它們,確保惡意Javascript代碼在受害人的機器上運行。這些攻擊利用了用戶和伺服器之間的信任關系,事實上伺服器沒有對輸
入、輸出進行檢測,從而未拒絕javascript代碼。
這篇文章討論SQL注入和CSS攻擊漏洞的檢測技術。網上已經有很多關於這兩種基於
WEB攻擊的討論,比如如何實施攻擊,他們的影響,怎樣更好的編制和設計程序防止這些攻擊。 然而,
對如何檢測這些攻擊並沒有足夠的討論。我們採用流行的開源的IDS Snort[ref
3],組建根據檢測這些攻擊的規則的正則表達式。附帶,Snort默認規則設定包含檢測CSS的方法,但是這些容易被避開檢測。比如大多通過hex進制編
碼,如%3C%73%63%72%69%70% 74%3E代替避開檢測。
依賴level of
paranoia組織的能力,我們已經編寫了多種檢測相同攻擊的規則。如果你希望檢測各種可能的SQL注入攻擊,那麼你需要簡單的留意任何現行的SQL
meta-characters,如單引號,分號和雙重破折號。同樣的一個極端檢測CSS攻擊的方法,只要簡單地提防HTML標記的角括弧。但這樣會檢測
出很多錯誤。為了避免這些,這些規則需要修改使它檢測更精確些, 當仍然不能避免錯誤。
在Snort規則中使用pcre(Perl
Compatible Regular
Expressions)[ref4]關鍵字,每個規則可以帶或不帶其他規則動作。這些規則也可以被公用軟體如grep(文檔搜索工具)使用,來審閱網路
伺服器日誌。 但是,需要警惕的是,用戶的輸入只有當以GET提交請求時,WEB伺服器才會記錄日記,如果是以POST提交的請求在日記中是不會記錄的。
2. SQL注入的正則表示式

你為SQL注入攻擊選擇正則表示式的時候,重點要記住攻擊者可以通過提交表單進行SQL注入,也可以通過Cookie區域。你的輸入檢測邏輯應該考慮用戶

組織的各類型輸入(比如表單或Cookie信息)。並且如果你發現許多警告來自一個規則,請留意單引號或者是分號,也許些字元是你的Web應用程序創造的
合法的在CookieS中的輸入。因此, 您需要根據你的特殊的WEB應用程序評估每個規則。
依照前面提到,一個瑣細的檢測SQL射入攻擊的正則表達式要留意SQL特殊的meta-characters 譬如單引號(』)雙重擴則號(--),為了查出這些字元和他們hex等值數, 以下正則表達式適用:
2.1 檢測SQL meta-characters的正則表達式
/(\%27)|(\』)|(\-\-)|(\%23)|(#)/ix
解釋:

們首先檢查單引號等值的hex,單引號本身或者雙重擴折號。這些是MS SQL Server或Oracle的字元, 表示後邊的為評論,
隨後的都將被忽略。 另外,如果你使用MySQL,你需要留意 』#』和它等值的hex的出現。注意我們不需要檢查雙重破折號等值的hex,
因為這不是HTML meta-character, 瀏覽器不會進行編碼。 並且,
如果攻擊者設法手工修改雙重破折號為它的hex值%2D(使用代理像Achilles[ref 5]), SQL注入將失敗。
加入上述正則表達式的新的Snort規則如下:
alert
tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL
Injection - Paranoid";
flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\』)|(\-\-)|(%23)|(#)/i";
classtype:Web-application-attack; sid:9099; rev:5;)
在本篇討論中,
uricontent關鍵字的值為".pl ", 因為在我們的測試環境里, CGI
程序是用Perl寫的。uricontent關鍵字的值取決於您的特殊應用, 這個值也許是".php ", 或" .asp ", 或" .jsp
", 等。 從這點考慮, 我們不顯示對應的Snort 規則, 但是我們會給出創造這些規則的正則表達式。
通過這些正則表達式你可以很簡單的創造很多的Snort規則.在前面的正則表達式里,
我們檢測雙重破折號是因為:即便沒有單引號的存在那裡也可能是SQL射入點[ref 6]。 例如, SQL查詢條目只包含數值,如下:
select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number
這種情況,攻擊者可以執行額外的SQL查詢, 示範提交如下輸入:
3; insert values into some_other_table
最後, pcre的修飾符』 i』 和』 x 』 是用於分別匹配大小寫和忽略空白處的。 上面的規則也可以另外擴展來檢查分號的存在。然而,分號很可以是正常HTTP應答的一部分。為了減少這種錯誤,也是為了任何正常的單引號和雙重擴折號的出
現,上面的規則應該被修改成先檢測=號的存。用戶輸入會響應一個GET或POST請求,一般輸入提交如下:
username=some_user_supplied_value&password=some_user_supplied_value
因此, SQL 注入嘗試將導致用戶的輸入出現在a = 號或它等效的hex值之後。
2.2 修正檢測SQL meta-characters的正則表達式
/((\%3D)|(=))[^\n]*((\%27)|(\』)|(\-\-)|(\%3B)|(:))/i
解釋:
這個規則首先留意 = 號或它的hex值(%3D),然後考慮零個或多個除換行符以外的任意字元,最後檢測單引號,雙重破折號或分號。

型的SQL注入會嘗試圍繞單引號的用途操作原來的查詢,以便得到有用的價值。討論這個攻擊一般使用1』or』1』=』1字元串. 但是,
這個串的偵查很容易被逃避,譬如用1』or2>1 --.
然而唯一恆定的部分是最初的字元的值,跟隨一單引號,再加』or』。隨後的布爾邏輯可能在一定范圍上變化,可以是普通樣式也可能是非常復雜的。這些攻擊可
以相當精確被偵測,通過以下的正則表達式。2.3章節講解。
2.3 典型的 SQL 注入攻擊的正則表達式
/\w*((\%27)|(\』))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
解釋:
\w* - 零個或多個字元或者下劃線。
(\%27)|\』 - 單引號或它的hex等值。
(\%6 F)|o|(\%4 F))((\%72)|r|-(\%52) -『or』的大小寫以及它的hex等值。
』union』SQL
查詢在SQL注入各種資料庫中攻擊中同樣是很常見的。如果前面的正則表達式僅僅檢測單引號或則其他的SQL meta characters
,會造成很多的錯誤存在。你應該進一步修改查詢,檢測單引號和關鍵字『union』。這同樣可以進一步擴展其他的SQL關鍵字,像』select』,
』insert』, 』update』, 』delete』, 等等。
2.4 檢測SQL注入,UNION查詢關鍵字的正則表達式
/((\%27)|(\』))union/ix
(\%27)|(\』) - 單引號和它的hex等值
union - union關鍵字
可以同樣為其他SQL查詢定製表達式,如 >select, insert, update, delete, drop, 等等.

果,到這個階段,攻擊者已經發現web應用程序存在SQL注入漏洞,他將嘗試利用它。如果他認識到後端伺服器式MS SQL
server,他一般會嘗試運行一些危險的儲存和擴展儲存過程。這些過程一般以『sp』或『xp』字母開頭。典型的,他可能嘗試運行
『xp_cmdshell』擴展儲存過程(通過SQL Server執行Windows
命令)。SQL伺服器的SA許可權有執行這些命令的許可權。同樣他們可以通過xp_regread, xp_regwrite等儲存過程修改注冊表。
2.5 檢測MS SQL Server SQL注入攻擊的正則表達式
/exec(\s|\+)+(s|x)p\w+/ix
解釋:
exec - 請求執行儲存或擴展儲存過程的關鍵字
(\s|\+)+ - 一個或多個的空白或它們的http等值編碼
(s|x) p- 『sp』或『xp』字母用來辨認儲存或擴展儲存過程
\w+ - 一個或多個字元或下劃線來匹配過程的名稱
3. 跨站腳本(CSS)的正則表達式

發動CSS攻擊或檢測一個網站漏洞的時候, 攻擊者可能首先使簡單的HTML標簽如(粗體),(斜體)或(下劃線),或者他可能嘗試簡單的
script標簽如alert("OK").
因為大多數出版物和網路傳播的檢測網站是否有css漏洞都拿這個作為例子。這些嘗試都可以很簡單的被檢測出來。
然而,高明點的攻擊者可能用它的hex值替換整個字元串。這樣標簽會以%3C%73%63%72%69%70%74%3E出 現。
另一方面,攻擊者可能使用web代理伺服器像Achilles會自動轉換一些特殊字元如換成%3E.這樣攻擊發生時,URL
中通常以hex等值代替角括弧。
下列正則表達式將檢測任何文本中包含的html的。它將捉住試圖使用、、或。這正則表達式應該忽略大小寫。我們需要同時檢測角括弧和它的hex等值(% 3C|
3.1 一般 CSS 攻擊的正則表達式
/((\%3C)|)/ix
解釋:
((\%3C)|) -檢查>或它的hex等值
Snort 規則:
alert
tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII
Cross-site scripting attempt"; flow:to_server,established;
pcre:"/((\%3C)|)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
跨站腳本同樣可以使用技術。現行默認的snort規則可以被輕易避開。
3.2章節提供了防止這種技術的方法。
3.2 "
/((\%3C)|)/I
解釋:
(\%3 C)|) ->或它的hex等值
3.3 CSS 攻擊的極端的正則表達式
/((\%3C)|)/I
解釋:
這個規則簡單尋找。由於你的web伺服器和web應用程序的構架,這個規則可能產生一些錯誤。但它能保證捉住任何CCS或者類似CSS的攻擊。
一個不錯避開過濾的CSS方法請參考Bugtraq投稿的
http://www.securityfocus.com/archive/1/272...rchive/1/272037.
但是請注意最後一種極端的規則將能檢測這所有的攻擊。
總結:


這篇文章中,我們提出了不同種類的正則表達式規則來檢測SQL注入和跨站腳本攻擊。有些規則簡單而極端,一個潛在的攻擊都將提高警惕。但這些極端的規則可

能導致一些主動的錯誤。考慮到這點,我們修改了這些簡單的規則,利用了另外的樣式,他們可以檢查的更准確些。在這些網路應用成的攻擊檢測中,我們推薦將這
些作為調試你IDS或日誌分析方法的起點。再經過幾次修改後,在你對正常網交易部分的非惡意應答進行評估以後,你應該可以准備的檢測那些攻擊了。

❻ sql注入攻擊方法有哪些

所謂SQL注入式攻擊,就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字元串,欺騙伺服器執行惡意的SQL命令。在某些表單中,用戶輸入的內容直接用來構造(或者影響)動態SQL命令,或作為存儲過程的輸入參數,這類表單特別容易受到SQL注入式攻擊。常見的SQL注入式攻擊過程類如:
⑴ 某個ASP.NET Web應用有一個登錄頁面,這個登錄頁面控制著用戶是否有權訪問應用,它要求用戶輸入一個名稱和密碼。
⑵ 登錄頁面中輸入的內容將直接用來構造動態的SQL命令,或者直接用作存儲過程的參數。

❼ 網站如何防止sql注入攻擊的解決辦法

首先我們來了解下什麼是SQL注入,SQL注入簡單來講就是將一些非法參數插入到網站資料庫中去,執行一些sql命令,比如查詢資料庫的賬號密碼,資料庫的版本,資料庫伺服器的IP等等的一些操作,sql注入是目前網站漏洞中危害最大的一個漏洞,受攻擊的網站佔大多數都是sql注入攻擊。

sql注入攻擊用英語來講Structured Query Language,在網站的編程語言當中是一種比較另類的網站開發語言,我們網站安全行業通常來講sql是用來資料庫查詢的一種網站開發語言,同時也是一種腳本文件的一個文件名,通俗來講sql就是用來對網站的資料庫進行查詢,以及增加,寫入,更新資料庫的一個sql資料庫操作。

關於資料庫我們分為2種資料庫,一種是關系資料庫,非關系資料庫,那麼目前網站使用的都是關系資料庫,關系資料庫分為sql資料庫,microsoft sql server資料庫,ACC資料庫,mysql資料庫,oracle資料庫,DB2資料庫,postgresql資料庫等等的關系資料庫,非關系資料庫分為nosql資料庫,可以存儲很大數據,針對於一些並發較高,存儲較多,雲計算的場景,頻繁讀取寫入的資料庫,像memcachedb,redis,mongodb等等非關系資料庫。

那麼什麼是sql注入呢? 簡單來講就是對網站強行進行插入數據,執行sql惡意語句對網站進行攻擊,對網站進行sql注入嘗試,可以獲取一些私密的信息,像資料庫的版本,管理員的賬號密碼等等。

關於如何防止sql注入攻擊,我們從以下幾點開始入手

首先我們可以了解到sql注入攻擊都是通過拼接的方式,把一些惡意的參數拼接到一起,然後在網站的前端中插入,並執行到伺服器後端到資料庫中去,通常我們在寫PHP網站代碼的時候會將get ID這個參數值獲取到後直接拼接到後端伺服器中去,查詢資料庫,但是如果拼接了一些惡意的非法參數,那麼久可以當做sql語句來執行,如果防止sql注入呢?

為了防止網站被sql注入攻擊,我們應該從一開始寫代碼的時候就應該過濾一些sql注入的非法參數,將查詢的一些sql語句,以及用戶輸入的參數值都以字元串的方式來處理,不論用戶輸入的什麼東西,在sql查詢的時候只是一段字元串,這樣構造的任何惡意參數都會以字元串的方式去查詢資料庫,一直惡意的sql注入攻擊就不會被執行,sql注入語句也就沒有效果了,再一個就是網站里的任何一個可以寫入的地方盡可能的嚴格過濾與限制,漏下一個可以輸入的地方網站就會被攻擊,網站就會被黑,所有做的網站安全就會沒有效果,包括一些get,post,cookie方式的提交都是不可信的,像數據表裡referer user-agent等欄位都是可以偽造,寫入sql注入語句的,像前端時間爆發的ecshop漏洞利用的就是user.php,偽造referer參數進行了sql注入,執行了遠程代碼。

再一個防止sql注入的方法就是開啟PHP的魔術配置,開啟安全配置模式,將safe_mode開啟on.以及關閉全局變數模式,register_globals參數設置為on,magic_quotes_gpc參數開啟,防止sql注入.如果對網站防止sql注入不懂的話,也可以找專業的網站安全公司來做安全,防止sql注入。

❽ 如何對網站進行SQL注入

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

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

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

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

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