SINE安全對網站漏洞檢測具有的安全技術人員，而且完全不依靠軟件去掃描，所有漏洞檢測服務都是由我們人工去檢測，比如對代碼進行審計，以及都每個網站或APP的功能進行單的詳細測試，如跨權限漏洞，支付漏洞繞過，訂單價格被篡改，或訂單支付狀態之類的，或會員找回密碼這里被強制找回等，還有一些邏輯漏洞，上傳漏洞，垂直權限漏洞等等。
其實從開發的角度，如果要保證代碼至少在邏輯方面沒有明顯的漏洞，還是有些繁瑣的。舉個簡單的例子，如網站的數據檢驗功能，不允許前端提交不符合當前要求規范的數據（比如年齡文本框部分不能提交字母）。那么為了實現這個功能，首先開發者肯定要在前端實現該功能，直接在前端阻止用戶提交不符規范的數據，否則用戶體驗會很差，且占用服務器端的資源。
但是沒有安全意識或覺得麻煩的開發者就會僅僅在前端用Js進行校驗，后端沒有重復進行校驗。這樣就很容易給惡意用戶機會：比如不通過前端頁面，直接向后端接口發送數據：或者，前端代碼編寫不規范，用戶可以直接在瀏覽器控制臺中用自己寫的Js代碼覆蓋原有的Js代碼；或者，用戶還可以直接在瀏覽器中禁用Js；等等。總之，前端的傳過來的數據可信度基本上可以認為比較低，太容易被利用了。
而我的思路都是很簡單的，就是關注比較重要的幾個節點，看看有沒有可乘之機。如登錄、權限判定、數據加載等前后，對方是怎么做的，用了什么樣的技術，有沒有留下很明顯的漏洞可以讓我利用。像這兩個網站，加載的Js文檔都沒有進行混淆，注釋也都留著，還寫得很詳細。比較湊巧的是，這兩個網站都用到了比較多的前端的技術，也都用到了sessionStorage。

討論回顧完上次整改的問題之后，理清了思路。然后我登錄了網站查看一下原因，因為網站只有一個上傳圖片的地方，我進行抓包嘗試，使用了repeater重放包之后，發現返回包確實沒有返回文檔上傳路徑，然后我又嘗試了各種繞過，結果都不行。后苦思冥想得不到結果，然后去問一下這個云平臺給他們提供的這個告警是什么原因。看了云平臺反饋的結果里面查殺到有圖片碼，這個問題不大，上傳文檔沒有執行權限，而且沒有返回文檔路徑，還對文檔名做了隨機更改，但是為啥會有這個jsp上傳成功了，這讓我百思不得其解。
當我仔細云平臺提供的發現webshel數據的時候，我細心的觀察到了文檔名使用了base編碼，這個我很疑惑，都做了隨機函數了還做編碼干嘛，上次測試的時候是沒有做編碼的。我突然想到了問題關鍵，然后使用burpsuite的decoder模塊，將文檔名“1jsp”做了base編碼成“MS5Kc1A=”，然后發送成功反饋狀態碼200，再不是這個上傳失敗反饋500狀態碼報錯了。
所以，這個問題所在是，在整改過程中研發人員對這個文檔名使用了base編碼，導致文檔名在存儲過程中會使用base解析，而我上傳文檔的時候將這個后綴名.jsp也做了這個base編碼，在存儲過程中.jsp也被成功解析，研發沒有對解析之后進行白名單限制。其實這種編碼的更改是不必要的，畢竟原來已經做了隨機數更改了文檔名了，再做編碼有點畫蛇添足了，這就是為啥程序bug改一個引發更多的bug原因。

結合挖掘出敏感信息和加密算法，通常通過APP客戶端和服務器通信進行滲透攻擊，常見的通信方式有HTTP、Socket、WebSocket等，有這些重要信息后，客戶端指紋由于開發商缺乏安全意識，服務器和數據庫陷落，給客戶帶來了不可估量的損失。解決方案:做好服務器安全信任認證，提高開發人員的安全意識，讓我們的創造性安全進行安全評價和長期安全運輸，防止未來是的保護，如果想要對公司或自己的安卓APP或IOS-APP進行全面的安全滲透測試，檢測APP的安全性的話可以向SINESAFE,鷹盾安全，綠盟，大樹安全等等尋求這方面的服務，畢竟術業有專攻

多年以來，應用程序設計總是優先考慮功能性和可用性，很少考慮安全性。很多CISO表示，API安全性尤其不被重視，甚至完全被排除在安全設計流程之外。通常都是開發人員開發和部署完成后，在API投入生產且頻繁遭受攻擊后才亡羊補牢查找問題。安全性（包括API安全性）需要成為產品設計的一部分，并且應作為首要考慮因素加以實現，而不是事后填坑。
解決方法：審查應用程序的安全體系結構是邁向安全系統的重要步。請記住，API使攻擊者能更地攻擊或利用您的系統。設計安全性的目標是讓API成為用戶而非攻擊者的工具。以上只列舉了一些常見的API漏洞，總之，重要的是在軟件開發生命周期的早期階段就討論安全問題。微小的改進就可以帶來巨大的好處，避免API遭攻擊造成的巨大和損失。
SINE安全網站漏洞檢測時必須要人工去審計漏洞和查找漏洞找出問題所在并修復漏洞，對各項功能都進行了全面的安全檢測。
http://www.66bta.com