Posted on 2005-11-10 09:02 loop
閱讀
(136) 評論(1) ?編輯?收藏收藏至365Key
所屬分類
: 網絡安全 security
在最后
?
兩年中，安全專家應該對網絡應用層的攻擊更加重視。因為無論你有多強壯的
防火墻
規則設置或者非常勤于補漏的修補機制，如果你的網絡應用程序開發者沒有遵循
?
安全代碼進行開發，攻擊者將通過
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
代替
<script>
避開檢測。
依賴
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
標簽如
<b>(
粗體
),<i>(
斜體
)
或
<u>(
下劃線
)
，或者他可能嘗試簡單的
?script
標簽如
<script>alert("OK")</script>.?
因為大多數出版物和網絡傳播的檢測網站是否有
css漏洞
都拿這個作為例子。這些嘗試都可以很簡單的被檢測出來。
?
然而，高明點的攻擊者可能用它的
hex
值替換整個字符串。這樣
<script>
標簽會以
%3C%73%63%72%69%70%74%3E
出
?
現。
?
另一方面，攻擊者可能使用
web
代理服務器像
Achilles
會自動轉換一些特殊字符如
<
換成
%3C
、
>
換成
%3E.
這樣攻擊發生時，
URL?
中通常以
hex
等值代替角括號。
下列正則表達式將檢測任何文本中包含的
html
的
<
、
>
。它將捉住試圖使用
<?b>
、
<u>
、或
<script>
。這正則表達式應該忽略大小寫。我們需要同時檢測角括號和它的
hex
等值
(%?3C|<)
。檢測
hex
進制轉化的整個字符串，我們必須檢測用戶輸入的數字和
%
號，即使用
[a-z0-9%]?
。這可能會導致一些錯誤出現，不是大部分會檢測到真實攻擊的。
?
3.1?
一般
?CSS?
攻擊的正則表達式
/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/ix?
解釋
:
((\%3C)|<)?
－檢查
<
和它
hex
等值
((\%2F)|\/)*
－結束標簽
/
或它的
?hex
等值
[a-z0-9\%]+?
－檢查標簽里的字母或它
hex
等值
((\%3E)|>)?
－檢查
>
或它的
hex
等值
Snort?
規則
:?
alert?tcp?$EXTERNAL_NET?any?->?$HTTP_SERVERS?$HTTP_PORTS?(msg:"NII?Cross-site?scripting?attempt";?flow:to_server,established;?pcre:"/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i";?classtype:Web-application-attack;?sid:9000;?rev:5;)?
跨站腳本同樣可以使用
<img?src=>
技術。現行默認的
snort
規則可以被輕易避開。
3.2
章節提供了防止這種技術的方法。
3.2?"<img?src"?CSS?
攻擊正則表達式
/((\%3C)|<)((\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47))[^\n]+((\%3E)|>)/I?
解釋
:
(\%3?C)|<)?-<
或它的
hex
等值
(\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47)?-
’
img
’字母或它的大小寫
hex
等值的變化組合
[^\n]+?-
除了換行符以外的任何跟隨
<img
的字符
(\%3E)|>)?->
或它的
hex
等值
3.3?CSS?
攻擊的極端的正則表達式
/((\%3C)|<)[^\n]+((\%3E)|>)/I?
解釋
:
這個規則簡單尋找
<+
除換行符外的任何字符
+>
。由于你的
web
服務器和
web
應用程序的構架，這個規則可能產生一些錯誤。但它能保證捉住任何
CCS
或者類似
CSS
的攻擊。
一個不錯避開過濾的
CSS
方法請參考
Bugtraq
投稿的
http://www.securityfocus.com/archive/1/272...rchive/1/272037.?
但是請注意最后一種極端的規則將能檢測這所有的攻擊。
總結
:
在
?
這篇文章中，我們提出了不同種類的正則表達式規則來檢測
SQL
注入和跨站腳本攻擊。有些規則簡單而極端，一個潛在的攻擊都將提高警惕。但這些極端的規則可
?
能導致一些主動的錯誤。考慮到這點，我們修改了這些簡單的規則，利用了另外的樣式，他們可以檢查的更準確些。在這些網絡應用成的攻擊檢測中，我們推薦將這
?
些作為調試你
IDS
或日志分析方法的起點。再經過幾次修改后，在你對正常網交易部分的非惡意應答進行評估以后，你應該可以準備的檢測那些攻擊了。
??????????????