1. 介紹
在 最後兩年中，安全專家應該對網路套用層的攻擊更加重視。因為無論你有多強壯的防火牆規則設定或者非常勤於補漏的修補機制，如果你的網路應用程式開發者沒有 遵循安全程式碼進行開發，攻擊者將通過80連接阜進入你的系統。
廣泛被使用的兩個主要攻擊技術是SQL注入[ref 1] 和CSS[ref 2] 攻擊。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替代<script>避開檢測。
依賴level of paranoia組織的能力，我們已經編寫了多種檢測相同攻擊的規則。如果你希望檢測各種可能的SQL注入攻擊，那麼你需要簡單的留意任何現行的SQL meta-characters，如單引號，分號和雙重破折號。
同樣的一個極端檢測CSS攻擊的方法，只要簡單地提防HTML標記的角括號。但這樣會檢測 出很多錯誤。為了避免這些，這些規則需要修改使它檢測更精確些, 當仍然不能避免錯誤。
在Snort規則中使用pcre(Perl Compatible Regular Expressions)關鍵字，每個規則可以帶或不帶其他規則動作。這些規則也可以被公用軟體如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注入漏洞，他將嘗試利用它。