好，第二個的話，就是咱們?nèi)プ龉δ軠y試的話，你要知道你我們經(jīng)常做的一些測試的策略有哪一些，然后你是從哪些角度去做這一些測試策略的比如說這些測試策略的話有咱們的功能測試，然后 UI 兼容性測試、穩(wěn)定性測試，那這些東西你如何去做你是如何去實施的，你會從哪些角度去測試，這個也是做做咱們黑盒測試必須要掌握的一個。
早上，我突然被客戶告知，他部署在云平臺的服務(wù)器被檢測到webshell，已經(jīng)查殺了，而且云平臺檢測到這個ip是屬于我公司的，以為是我們公司做了測試導(dǎo)致的，問我這個怎么上傳的webshell，我當(dāng)時也是一臉懵逼，我記得很清楚這是我的項目，是我親自測試的，上傳點不會有遺漏的，然后開始了我的排查隱患工作。
巡檢查殺首先，我明白自己要做的不是找到這個上傳的位置是哪里出現(xiàn)的，我應(yīng)該登上服務(wù)器進行webshel查殺，進行巡檢，找找看是否被別人入侵了，是否存在后門等等情況。雖然報的是我們公司的ip，萬一漏掉了幾個webshell，被別人上傳成功了沒檢測出來，那服務(wù)器被入侵了如何能行。所以我上去巡檢了服務(wù)器，上傳這個webshell查殺工具進行查殺，使用netstat-anpt和iptables-L判斷是否存在后門建立，查看是否有程序占用CPU，等等，此處不詳細展開了。萬幸的是服務(wù)器沒有被入侵，然后我開始著手思考這個上傳點是怎么回事。
文檔上傳漏洞回顧首先，我向這個和我對接的研發(fā)人員咨詢這個服務(wù)器對外開放的，要了之后打開發(fā)現(xiàn)，眼熟的不就是前不久自己測試的嗎？此時，我感覺有點懵逼，和開發(fā)人員對質(zhì)起這個整改信息，上次測試完發(fā)現(xiàn)這個上傳的地方是使用了白名單限制，只允許上傳jpeg、png等圖片格式了。當(dāng)時我還發(fā)現(xiàn)，這個雖然上傳是做了白名單限制，也對上傳的文檔名做了隨機數(shù)，還匹配了時間規(guī)則，但是我還是在返回包發(fā)現(xiàn)了這個上傳路徑和文檔名，這個和他提議要進行整改，不然這個會造成這個文檔包含漏洞，他和我反饋這個確實進行整改了，沒有返回這個路徑了。

大多數(shù)開發(fā)人員沒有安全意識，其中軟件開發(fā)公司更嚴(yán)重。他們專注于實現(xiàn)客戶的需求，不考慮現(xiàn)在的代碼是否有安全上的危險。在生產(chǎn)軟件的同時，也生產(chǎn)脆弱性，沒有任何軟件是的，沒有脆弱性。因此，建議網(wǎng)絡(luò)安全技術(shù)人員對代碼進行安全審計，挖掘漏洞，避免風(fēng)險。無論是大型軟件還是小型軟件，安全穩(wěn)定都是APP運營的標(biāo)準(zhǔn)。否則，即使是更好的商業(yè)模式也無法忍受網(wǎng)絡(luò)攻擊的推敲。大型軟件受到競爭對手和黑產(chǎn)組織的威脅，小型軟件通過掃描式隨機攻擊侵入服務(wù)器，稍有疏忽的平臺被利用。

近，攻擊者接管賬戶的嘗試在不斷增加。錯誤消息過于“詳細周到”，往往使此類攻擊更加容易。冗長的錯誤消息會引導(dǎo)攻擊者了解他們需要進行哪些更改才能偽裝成合法請求。API專為低負載下的高速交易而設(shè)計，使攻擊者可以使用高性能系統(tǒng)找出有效賬戶，然后嘗試登錄并更改密碼進行利用。解決方法：不要拿用戶體驗作為擋牌，有些看起來有利于用戶體驗的做法，未必有利于安全性。系統(tǒng)返回的錯誤信息不應(yīng)該包括錯誤的用戶名或錯誤的密碼，甚至不能包含錯誤信息的類別（用戶名還是密碼錯誤）。用于查詢數(shù)據(jù)的錯誤消息也是如此，如果查詢/搜索格式不正確或由于某種原因而無法執(zhí)行，則應(yīng)該返回“沒有營養(yǎng)”的錯誤信息：“糟糕，哪里出錯了”。

文件上傳漏洞。造成文件上傳漏洞的主要原因是應(yīng)用程序中有上傳功能，但上傳的文件沒有通過嚴(yán)格的合法性檢查或者檢查功能有缺陷，導(dǎo)致木馬文件上傳到服務(wù)器。文件上傳漏洞危害大，因為惡意代碼可以直接上傳到服務(wù)器，可能造成服務(wù)器網(wǎng)頁修改、網(wǎng)站暫停、服務(wù)器遠程控制、后門安裝等嚴(yán)重后果。文件上傳的漏洞主要是通過前端JS旁路、文件名旁路和Content-Type旁路上傳惡意代碼。
SINE安全網(wǎng)站漏洞檢測時必須要人工去審計漏洞和查找漏洞找出問題所在并修復(fù)漏洞，對各項功能都進行了全面的安全檢測。
http://www.cxftmy.com