關于黑盒測試中的業務功能安全測試，個如果說你是去做那種性比較強的這一種業務，比如說咱們的這一個銀行類的金融類的這些業務，那么它可能個要求就是你要有這個什么業務能力。 因為有時候一些復雜的業務的話，并不是說如果說以前你沒做的話，他可能就光這個業務的培訓那就要給你來個三個月或甚至半年的一個時間，因此說對于這一種業務能力要求比較高的這種項目或者企業里面去招人的話，他個看中或者說他有一個硬性的要求，就是說你有沒有做過相關的這一些產品，如果做過的話，這一類人員他是優先的。
討論回顧完上次整改的問題之后，理清了思路。然后我登錄了網站查看一下原因，因為網站只有一個上傳圖片的地方，我進行抓包嘗試，使用了repeater重放包之后，發現返回包確實沒有返回文檔上傳路徑，然后我又嘗試了各種繞過，結果都不行。后苦思冥想得不到結果，然后去問一下這個云平臺給他們提供的這個告警是什么原因。看了云平臺反饋的結果里面查殺到有圖片碼，這個問題不大，上傳文檔沒有執行權限，而且沒有返回文檔路徑，還對文檔名做了隨機更改，但是為啥會有這個jsp上傳成功了，這讓我百思不得其解。
當我仔細云平臺提供的發現webshel數據的時候，我細心的觀察到了文檔名使用了base編碼，這個我很疑惑，都做了隨機函數了還做編碼干嘛，上次測試的時候是沒有做編碼的。我突然想到了問題關鍵，然后使用burpsuite的decoder模塊，將文檔名“1jsp”做了base編碼成“MS5Kc1A=”，然后發送成功反饋狀態碼200，再不是這個上傳失敗反饋500狀態碼報錯了。
所以，這個問題所在是，在整改過程中研發人員對這個文檔名使用了base編碼，導致文檔名在存儲過程中會使用base解析，而我上傳文檔的時候將這個后綴名.jsp也做了這個base編碼，在存儲過程中.jsp也被成功解析，研發沒有對解析之后進行白名單限制。其實這種編碼的更改是不必要的，畢竟原來已經做了隨機數更改了文檔名了，再做編碼有點畫蛇添足了，這就是為啥程序bug改一個引發更多的bug原因。

文件上傳漏洞。造成文件上傳漏洞的主要原因是應用程序中有上傳功能，但上傳的文件沒有通過嚴格的合法性檢查或者檢查功能有缺陷，導致木馬文件上傳到服務器。文件上傳漏洞危害大，因為惡意代碼可以直接上傳到服務器，可能造成服務器網頁修改、網站暫停、服務器遠程控制、后門安裝等嚴重后果。文件上傳的漏洞主要是通過前端JS旁路、文件名旁路和Content-Type旁路上傳惡意代碼。

早上，我突然被客戶告知，他部署在云平臺的服務器被檢測到webshell，已經查殺了，而且云平臺檢測到這個ip是屬于我公司的，以為是我們公司做了測試導致的，問我這個怎么上傳的webshell，我當時也是一臉懵逼，我記得很清楚這是我的項目，是我親自測試的，上傳點不會有遺漏的，然后開始了我的排查隱患工作。
巡檢查殺首先，我明白自己要做的不是找到這個上傳的位置是哪里出現的，我應該登上服務器進行webshel查殺，進行巡檢，找找看是否被別人入侵了，是否存在后門等等情況。雖然報的是我們公司的ip，萬一漏掉了幾個webshell，被別人上傳成功了沒檢測出來，那服務器被入侵了如何能行。所以我上去巡檢了服務器，上傳這個webshell查殺工具進行查殺，使用netstat-anpt和iptables-L判斷是否存在后門建立，查看是否有程序占用CPU，等等，此處不詳細展開了。萬幸的是服務器沒有被入侵，然后我開始著手思考這個上傳點是怎么回事。
文檔上傳漏洞回顧首先，我向這個和我對接的研發人員咨詢這個服務器對外開放的，要了之后打開發現，眼熟的不就是前不久自己測試的嗎？此時，我感覺有點懵逼，和開發人員對質起這個整改信息，上次測試完發現這個上傳的地方是使用了白名單限制，只允許上傳jpeg、png等圖片格式了。當時我還發現，這個雖然上傳是做了白名單限制，也對上傳的文檔名做了隨機數，還匹配了時間規則，但是我還是在返回包發現了這個上傳路徑和文檔名，這個和他提議要進行整改，不然這個會造成這個文檔包含漏洞，他和我反饋這個確實進行整改了，沒有返回這個路徑了。

這在目前的互聯網環境下，很容易出現安全問題，比如被攻擊、被掛馬、被用戶數據等等，尤其是本身在代碼安全層面做的并不好的情況下，這種事件就更容易發生，再加上，這些中小企業普遍缺乏網絡安全投資和必要防護手段，抗擊打能力比較弱，一旦遭到網絡攻擊，蒙受巨大經濟損失后將很難恢復元氣。
SINE安全網站漏洞檢測時必須要人工去審計漏洞和查找漏洞找出問題所在并修復漏洞，對各項功能都進行了全面的安全檢測。
http://www.66bta.com