A. 如何檢測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語句的變數
B. 測試登陸頁面時，如何測試SQL注入漏洞呢
許多網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼(一般是在瀏覽器地址欄進行,通過正常的www埠訪問)，根據程序返回的結果，獲得某些想得知的數據，這就是所謂的SQL Injection，即SQL注入。
網站的惡夢——SQL注入
SQL注入通過網頁對網站資料庫進行修改。它能夠直接在資料庫中添加具有管理員許可權的用戶，從而最終獲得系統管理員許可權。黑客可以利用獲得的管理員許可權任意獲得網站上的文件或者在網頁上加掛木馬和各種惡意程序，對網站和訪問該網站的網友都帶來巨大危害。
防禦SQL注入有妙法
第一步:很多新手從網上下載SQL通用防注入系統的程序，在需要防範注入的頁面頭部用來防止別人進行手動注入測試。
可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾，你的管理員賬號及密碼就會被分析出來。
第二步:對於注入分析器的防範，通過實驗，發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中，發現軟體並不是沖著「admin」管理員賬號去的，而是沖著許可權(如flag=1)去的。這樣一來，無論你的管理員賬號怎麼變都無法逃過檢測。
第三步:既然無法逃過檢測，那我們就做兩個賬號，一個是普通的管理員賬號，一個是防止注入的賬號，如果找一個許可權最大的賬號製造假象，吸引軟體的檢測，而這個賬號里的內容是大於千字以上的中文字元，就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。
1.對表結構進行修改。將管理員的賬號欄位的數據類型進行修改，文本型改成最大欄位255(其實也夠了，如果還想做得再大點，可以選擇備注型)，密碼的欄位也進行相同設置。
2.對表進行修改。設置管理員許可權的賬號放在ID1，並輸入大量中文字元(最好大於100個字)。
3.把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。
我們通過上面的三步完成了對資料庫的修改。
另外要明白您做的ID1賬號其實也是真正有許可權的賬號，現在計算機處理速度那麼快，要是遇上個一定要將它算出來的軟體，這也是不安全的。只要在管理員登錄的頁面文件中寫入字元限制就行了，就算對方使用這個有上千字元的賬號密碼也會被擋住的，而真正的密碼則可以不受限制。
C. 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.
D. 如何判斷是否存在SQL注入以及注入類型
許多網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼，根據程序返回的結果，獲得某些想得知的數據，這就是所謂的SQL Injection，即SQL注入。如何判斷網站是否存在POST注入呢！請看以下步驟操作做。
POST注入操作介紹:
1.POST注入一般發生在表單數據傳輸時、抓取POST提交的數據進行SQL語句測試
POST注入操作流程:
比如抓取的POST數據為:userName=admin&password=admin
測試諸如語句填寫:userName=admin&password='admin 1=1--
像這樣userName 參數後面加一些SQL語句(注入測試語句)進行POST數據注入測試即可。
E. 如何防範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許可權用戶的訪問，對不同的資料庫劃分不同的用戶許可權，這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作，就可以防止不同用戶對非授權的資料庫進行訪問。
F. 如何測試一個網站是不是可以被SQL注入
SQL注入通過網頁對網站資料庫進行修改。它能夠直接在資料庫中添加具有管理員許可權的用戶，從而最終獲得系統管理員許可權。黑客可以利用獲得的管理員許可權任意獲得網站上的文件或者在網頁上加掛木馬和各種惡意程序，對網站和訪問該網站的網友都帶來巨大危害。
防禦SQL注入有妙法
第一步:很多新手從網上下載SQL通用防注入系統的程序，在需要防範注入的頁面頭部用來防止別人進行手動注入測試。
可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾，你的管理員賬號及密碼就會被分析出來。
第二步:對於注入分析器的防範，通過實驗，發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中，發現軟體並不是沖著「admin」管理員賬號去的，而是沖著許可權(如flag=1)去的。這樣一來，無論你的管理員賬號怎麼變都無法逃過檢測。
第三步:既然無法逃過檢測，那我們就做兩個賬號，一個是普通的管理員賬號，一個是防止注入的賬號，如果找一個許可權最大的賬號製造假象，吸引軟體的檢測，而這個賬號里的內容是大於千字以上的中文字元，就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。
1.對表結構進行修改。將管理員的賬號欄位的數據類型進行修改，文本型改成最大欄位255(其實也夠了，如果還想做得再大點，可以選擇備注型)，密碼的欄位也進行相同設置。
2.對表進行修改。設置管理員許可權的賬號放在ID1，並輸入大量中文字元(最好大於100個字)。
3.把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。
我們通過上面的三步完成了對資料庫的修改。
另外要明白您做的ID1賬號其實也是真正有許可權的賬號，現在計算機處理速度那麼快，要是遇上個一定要將它算出來的軟體，這也是不安全的。只要在管理員登錄的頁面文件中寫入字元限制就行了，就算對方使用這個有上千字元的賬號密碼也會被擋住的，而真正的密碼則可以不受限制。
G. 如何判斷資料庫被SQL注入漏洞
SQL注入一般會在http://xxx.xxx.xxx/abc.asp?id=XX這樣等帶有參數的ASP動態網頁中，有些動態網頁中可能只有一個參數，有些可能有n個參數；有些參數是整型，有些參數是字元串型。只要是帶有參數的動態網頁訪問了資料庫就有可能存在SQL注入。
我們首選要修改瀏覽器的設置，以便更好的了解動態網頁參數里包含的信息。以IE瀏覽器為例，把IE菜單-工具-Internet選項－高級－顯示友好HTTP錯誤信息前面的勾去掉。
下面以http://xxx.xxx.xxx/abc.asp?p=YY為例進行分析，「YY」可能是整型，也有可能是字元串。
1、整型參數的判斷
當輸入的參數YY為整型時，通常abc.asp中SQL語句原貌大致如下：
select * from 表名 where 欄位=YY，所以可以用以下步驟測試SQL注入是否存在。
（1）http://xxx.xxx.xxx/abc.asp?p=YY and 1=2, abc.asp運行異常；
（2）http://xxx.xxx.xxx/abc.asp?p=YY』(附加一個單引號)，此時abc.ASP中的SQL語句變成了select * from 表名 where 欄位=YY』，abc.asp運行異常；
（3）http://xxx.xxx.xxx/abc.asp?p=YY and 1=1, abc.asp運行正常，而且與http://xxx.xxx.xxx/abc.asp?p=YY運行結果相同；
如果這三個方面全部滿足，abc.asp中一定存在SQL注入漏洞！
2、字元串型參數的判斷
當輸入的參數YY為字元串時，通常abc.asp中SQL語句原貌大致如下：
select * from 表名 where 欄位=』YY』，所以可以用以下步驟測試SQL注入是否存在。
（1）http://xxx.xxx.xxx/abc.asp?p=YY&nb … 39;1』=』2′, abc.asp運行異常；
（2）http://xxx.xxx.xxx/abc.asp?p=YY&nb … 39;1』=』1′, abc.asp運行正常，而且與http://xxx.xxx.xxx/abc.asp?p=YY運行結果相同；
（3）http://xxx.xxx.xxx/abc.asp?p=YY』(附加一個單引號)，此時abc.ASP中的SQL語句變成了select * from 表名 where 欄位=YY』，abc.asp運行異常；
如果這三個方面全部滿足，abc.asp中一定存在SQL注入漏洞！
3、字元被過濾的判斷
有安全意識的ASP程序員會過濾掉單引號等字元，以防止SQL注入。這種情況可以用下面幾種方法嘗試。
（1）ASCII方法:所有的輸入部分或全部字元的ASCII代碼,如U = CRH(85),一個= CRH(97),等等。
(2)UNICODE方法:在IIS UNICODE字元集實現國際化,我們可以在輸入字元串即輸入UNICODE字元串。如+ = % 2 b,空格= % 20,等;
(1)混合設置方法:大小是大小寫不敏感的,因為根據當時和過濾器的程序員通常要麼過濾所有大寫字母的字元串,或過濾所有小寫的字元串,大小寫混合往往會被忽略。如用SelecT代替select,SELECT等。
H. 如何檢測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或日誌分析方法的起點。再經過幾次修改後，在你對正常網交易部分的非惡意應答進行評估以後，你應該可以准備的檢測那些攻擊了。
I. 新手怎麼做好介面測試
介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。介面測試范圍
a)業務功能（包括正常、異常場景是否實現）
b)業務規則（覆蓋度是否全面）
c)參數驗證（邊界、業務規則是否達到要求）
d)異常場景（重復提交、並發提交、事務中斷、多機環境、大數據量測試）
e)性能測試（響應時間、吞吐量、並發數、資源要求）
f)安全測試（許可權驗證、SQL注入等）