雖然現(xiàn)在的網(wǎng)站安全防護(hù)技術(shù)已經(jīng)得到了很大的提升，但是相應(yīng)地，一些網(wǎng)站入侵技術(shù)也會(huì)不斷地升級(jí)、進(jìn)化。如何建設(shè)網(wǎng)站，因此，企業(yè)在進(jìn)行網(wǎng)站建設(shè)管理的時(shí)候，一定不可以輕視網(wǎng)站安全這一塊，建議企業(yè)周期性、長(zhǎng)期性地用一些基本方法來(lái)檢測(cè)企業(yè)網(wǎng)站的安全性，確保網(wǎng)站順利、正常地運(yùn)營(yíng)下去。
修改后臺(tái)初始密碼
每個(gè)都有一個(gè)后臺(tái)賬戶，用于日常的維護(hù)更新，而很多后臺(tái)初始密碼都過于簡(jiǎn)單，在拿到后臺(tái)管理賬號(hào)密碼時(shí)，要先把初始密碼修改掉，帳號(hào)密碼要有一定的復(fù)雜度，不要使用域名、年份、姓名、純數(shù)字等元素，要知道密碼越好記也就意味著越容易被攻破。

其實(shí)從開發(fā)的角度，如果要保證代碼至少在邏輯方面沒有明顯的漏洞，還是有些繁瑣的。舉個(gè)簡(jiǎn)單的例子，如網(wǎng)站的數(shù)據(jù)檢驗(yàn)功能，不允許前端提交不符合當(dāng)前要求規(guī)范的數(shù)據(jù)（比如年齡文本框部分不能提交字母）。那么為了實(shí)現(xiàn)這個(gè)功能，首先開發(fā)者肯定要在前端實(shí)現(xiàn)該功能，直接在前端阻止用戶提交不符規(guī)范的數(shù)據(jù)，否則用戶體驗(yàn)會(huì)很差，且占用服務(wù)器端的資源。
但是沒有安全意識(shí)或覺得麻煩的開發(fā)者就會(huì)僅僅在前端用Js進(jìn)行校驗(yàn)，后端沒有重復(fù)進(jìn)行校驗(yàn)。這樣就很容易給惡意用戶機(jī)會(huì)：比如不通過前端頁(yè)面，直接向后端接口發(fā)送數(shù)據(jù)：或者，前端代碼編寫不規(guī)范，用戶可以直接在瀏覽器控制臺(tái)中用自己寫的Js代碼覆蓋原有的Js代碼；或者，用戶還可以直接在瀏覽器中禁用Js；等等?？傊岸说膫鬟^來(lái)的數(shù)據(jù)可信度基本上可以認(rèn)為比較低，太容易被利用了。
而我的思路都是很簡(jiǎn)單的，就是關(guān)注比較重要的幾個(gè)節(jié)點(diǎn)，看看有沒有可乘之機(jī)。如登錄、權(quán)限判定、數(shù)據(jù)加載等前后，對(duì)方是怎么做的，用了什么樣的技術(shù)，有沒有留下很明顯的漏洞可以讓我利用。像這兩個(gè)網(wǎng)站，加載的Js文檔都沒有進(jìn)行混淆，注釋也都留著，還寫得很詳細(xì)。比較湊巧的是，這兩個(gè)網(wǎng)站都用到了比較多的前端的技術(shù)，也都用到了sessionStorage。

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

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