雖然現(xiàn)在的網(wǎng)站安全防護(hù)技術(shù)已經(jīng)得到了很大的提升，但是相應(yīng)地，一些網(wǎng)站入侵技術(shù)也會不斷地升級、進(jìn)化。如何建設(shè)網(wǎng)站，因此，企業(yè)在進(jìn)行網(wǎng)站建設(shè)管理的時候，一定不可以輕視網(wǎng)站安全這一塊，建議企業(yè)周期性、長期性地用一些基本方法來檢測企業(yè)網(wǎng)站的安全性，確保網(wǎng)站順利、正常地運(yùn)營下去。
以盜幣為主要目的的攻擊并非個例，隨著以為代表的數(shù)字的盛行，世界各地的交易中心成為了攻擊的一個新目標(biāo)，頻頻爆出遭遇的攻擊，用戶賬戶被盜、用戶數(shù)據(jù)泄露、損失慘重等事件。

云的簡化運(yùn)維特性可以幫用戶降低這方面風(fēng)險，但如果用戶在架構(gòu)上并沒有針對性的做署，安全問題仍然很突出。相比而言，大部分大企業(yè)有的 IT 部門，配備的信息安全團(tuán)隊，每年有信息安全方面的預(yù)算，有助于他們抵御網(wǎng)絡(luò)攻擊和修復(fù)漏洞。如此一來，當(dāng)同樣受到網(wǎng)絡(luò)攻擊時，中小企業(yè)受到的影響顯然更加顯著。

滲透測試其實就是一個攻防對抗的過程，所謂知己知彼，才能百戰(zhàn)百勝。如今的網(wǎng)站基本都有防護(hù)措施，大企業(yè)或大單位因為網(wǎng)站眾多，一般都會選擇大型防火墻作為保護(hù)措施，比如深信服、天融信等等，小單位或單個網(wǎng)站通常會選擇D盾、安全狗或開源的安全軟件作為保護(hù)措施，一些常見的開源waf有：OpenResty、ModSecurity、NAXSI、WebKnight、ShadowDaemon等等。
當(dāng)然，服務(wù)器沒裝防護(hù)的的網(wǎng)站還是有的。而這些防護(hù)措施都有對常見漏洞的防御措施，所以在實際的漏洞挖掘和利用過程中必須考慮這些問題，如何確定防護(hù)措施，如何對抗防護(hù)措施。web常見漏洞一直是變化的，隔一段時間就會有新的漏洞被發(fā)現(xiàn)，但實戰(zhàn)中被利用的漏洞其實就那么幾個，就像編程語言一樣，穩(wěn)坐前三的永遠(yuǎn)是c、c++。

討論回顧完上次整改的問題之后，理清了思路。然后我登錄了網(wǎng)站查看一下原因，因為網(wǎng)站只有一個上傳圖片的地方，我進(jìn)行抓包嘗試，使用了repeater重放包之后，發(fā)現(xiàn)返回包確實沒有返回文檔上傳路徑，然后我又嘗試了各種繞過，結(jié)果都不行。后苦思冥想得不到結(jié)果，然后去問一下這個云平臺給他們提供的這個告警是什么原因。看了云平臺反饋的結(jié)果里面查殺到有圖片碼，這個問題不大，上傳文檔沒有執(zhí)行權(quán)限，而且沒有返回文檔路徑，還對文檔名做了隨機(jī)更改，但是為啥會有這個jsp上傳成功了，這讓我百思不得其解。
當(dāng)我仔細(xì)云平臺提供的發(fā)現(xiàn)webshel數(shù)據(jù)的時候，我細(xì)心的觀察到了文檔名使用了base編碼，這個我很疑惑，都做了隨機(jī)函數(shù)了還做編碼干嘛，上次測試的時候是沒有做編碼的。我突然想到了問題關(guān)鍵，然后使用burpsuite的decoder模塊，將文檔名“1jsp”做了base編碼成“MS5Kc1A=”，然后發(fā)送成功反饋狀態(tài)碼200，再不是這個上傳失敗反饋500狀態(tài)碼報錯了。
所以，這個問題所在是，在整改過程中研發(fā)人員對這個文檔名使用了base編碼，導(dǎo)致文檔名在存儲過程中會使用base解析，而我上傳文檔的時候?qū)⑦@個后綴名.jsp也做了這個base編碼，在存儲過程中.jsp也被成功解析，研發(fā)沒有對解析之后進(jìn)行白名單限制。其實這種編碼的更改是不必要的，畢竟原來已經(jīng)做了隨機(jī)數(shù)更改了文檔名了，再做編碼有點(diǎn)畫蛇添足了，這就是為啥程序bug改一個引發(fā)更多的bug原因。
SINE安全網(wǎng)站漏洞檢測時必須要人工去審計漏洞和查找漏洞找出問題所在并修復(fù)漏洞，對各項功能都進(jìn)行了全面的安全檢測。
http://www.cxftmy.com