如何檢測SQL注入技術以及跨站指令碼攻擊

 

　　在最近兩年中，安全專家應該對網路應用程式層的攻擊更加重視。因為無論你有多強壯的防火牆規則設定或者非常勤於補漏的修補機制，如果你的網路應用程式開發人員沒有遵循安全的程式碼進行開發，攻擊者將通過80連接埠進入你的系統。廣泛被使用的兩個主要攻擊技術是SQL注入[ref1]和CSS[ref2]攻擊。SQL 注入是指：通過互連網的輸入地區，插入SQLmeta-characters（特殊字元代表一些資料）和指令，操縱執行後端的SQL查詢的技術。這些攻擊主要針對其他組織的WEB伺服器。CSS攻擊通過在URL裡插入script標籤，然後誘導信任它們的使用者點擊它們，確保惡意Javascript代碼在受害人的機器上運行。這些攻擊利用了使用者和伺服器之間的信任關係，事實上伺服器沒有對輸入、輸出進行檢測，從而未拒絕javascript代碼。

　　這篇文章討論SQL注入和CSS攻擊漏洞的檢測技術。網上已經有很多關於這兩種基於WEB攻擊的討論，比如如何實施攻擊，他們的影響，怎樣更好的編製和設計程式防止這些攻擊。然而，對如何檢測這些攻擊並沒有足夠的討論。我們採用流行的開源的IDSSnort[ref3]，組建根據檢測這些攻擊的規則的Regex。附帶，Snort預設規則設定包含檢測CSS的方法，但是這些容易被避開檢測。比如大多通過hex進位編碼，如%3C%73%63%72%69 %70%74%3E代替避開檢測。

　　依賴levelofparanoia組織的能力，我們已經編寫了多種檢測相同攻擊的規則。如果你希望檢測各種可能的SQL注入攻擊，那麼你需要簡單的留意任何現行的SQLmeta-characters，如單引號，分號和雙重破折號。同樣的一個極端檢測CSS攻擊的方法，只要簡單地提防HTML標記的角括弧。但這樣會檢測出很多錯誤。為了避免這些，這些規則需要修改使它檢測更精確些，當仍然不能避免錯誤。

　　在Snort規則中使用pcre(PerlCompatibleRegularExpressions)[ref4]關鍵字，每個規則可以帶或不帶其他規則動作。這些規則也可以被公用軟體如grep(文檔搜尋工具)使用，來審閱網路伺服器日誌。但是，需要警惕的是，使用者的輸入只有當以GET提交請求時，WEB伺服器才會記錄日記，如果是以POST提交的請求在日記中是不會記錄的。

　　2.SQL注入的正則表示式

　　當你為SQL注入攻擊選擇正則表示式的時候，重點要記住攻擊者可以通過提交表單進行SQL注入，也可以通過Cookie地區。你的輸入檢測邏輯應該考慮使用者組織的各類型輸入(比如表單或Cookie資訊)。並且如果你發現許多警告來自一個規則，請留意單引號或者是分號，也許些字元是你的Web應用程式創造的合法的在CookieS中的輸入。因此，您需要根據你的特殊的WEB應用程式評估每個規則。

　　依照前面提到，一個瑣細的檢測SQL射入攻擊的Regex要留意SQL特殊的meta-characters譬如單引號(’)雙重擴則號(--)，為了查出這些字元和他們hex等值數，以下Regex適用：

　　2.1檢測SQLmeta-characters的Regex

　　/(%27)|(’)|(--)|(%23)|(#)/ix

　　解釋:

　　我們首先檢查單引號等值的hex，單引號本身或者雙重擴折號。這些是MSSQLServer或Oracle的字元,表示後邊的為評論,隨後的都將被忽略。另外，如果你使用MySQL,你需要留意’#’和它等值的hex的出現。注意我們不需要檢查雙重破折號等值的hex,因為這不是HTMLmeta- character,瀏覽器不會進行編碼。並且,如果攻擊者設法手工修改雙重破折號為它的hex值%2D(使用代理像 Achilles[ref5]),SQL注入將失敗。

　　加入上述Regex的新的Snort規則如下:

　　 alerttcp$EXTERNAL_NETany->$HTTP_SERVERS$HTTP_PORTS(msg:"SQLInjection-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規則,但是我們會給出創造這些規則的Regex。通過這些Regex你可以很簡單的創造很多的Snort規則.在前面的Regex裡,我們檢測雙重破折號是因為：即便沒有單引號的存在那裡也可能是SQL射入點[ref6]。例如,SQL查詢條目只包含數值，如下:

　　selectvalue1,value2,num_value3fromdatabase

　　wherenum_value3=some_user_supplied_number

　　這種情況，攻擊者可以執行額外的SQL查詢,示範提交如下輸入:

　　3;insertvaluesintosome_other_table

　　最後,pcre的修飾符’i’和’x’是用於分別匹配大小寫和忽略空白處的。上面的規則也可以另外擴充來檢查分號的存在。然而，分號很可以是正常HTTP應答的一部分。為了減少這種錯誤，也是為了任何正常的單引號和雙重擴折號的出

　　現，上面的規則應該被修改成先檢測＝號的存。使用者輸入會響應一個GET或POST請求，一般輸入提交如下：

　　username=some_user_supplied_value&password=some_user_supplied_value

　　因此,SQL注入嘗試將導致使用者的輸入出現在a=號或它等效的hex值之後。

　　2.2修正檢測SQLmeta-characters的Regex

　　/((%3D)|(=))[^n]*((%27)|(’)|(--)|(%3B)|(:))/i