雖然現在的網站安全防護技術已經得到了很大的提升，但是相應地，一些網站入侵技術也會不斷地升級、進化。如何建設網站，因此，企業(yè)在進行網站建設管理的時候，一定不可以輕視網站安全這一塊，建議企業(yè)周期性、長期性地用一些基本方法來檢測企業(yè)網站的安全性，確保網站順利、正常地運營下去。
1.注入漏洞。由于其普遍性和嚴重性，注入漏洞在Web0漏洞中始終排在位。常見的注入漏洞包括SQL、LDAP、OS命令、ORM和OGNL。用戶可以通過任何輸入點輸入構建的惡意代碼。如果應用程序沒有嚴格過濾用戶的輸入，一旦輸入的惡意代碼作為命令或查詢的一部分被發(fā)送到解析器，就可能導致注入漏洞。以SQL注入為例，是因為攻擊者通過瀏覽器或其他客戶端向網站參數中插入惡意SQL語句，而網站應用程序直接將惡意SQL語句帶入數據庫并執(zhí)行而不進行過濾，終導致通過數據庫獲取敏感信息或其他惡意操作。

當攻擊者通過API調用遍歷攻擊系統(tǒng)時，他們必須弄清楚可以發(fā)送些什么來獲取數據。攻擊者“信奉”這樣的一個事實：即越復雜的系統(tǒng)，出錯的地方越多。攻擊者識別出API后，他們將對參數進行分類，然后嘗試訪問管理員（垂直特權升級）或另一個用戶（水平特權升級）的數據以收集其他數據。通常，太多不必要的參數被暴露給了用戶。
在近的研究項目中，我們對目標服務的API調用返回了大量數據，很多都是不必要的數據信息，例如付款網關的處理器密鑰和可用的折扣信息等。這些“獎勵信息”使攻擊者可以更好地理解這些API調用的上下文和語法。攻擊者不需要太多的想象力就能弄清楚下一步該怎么做。這些額外的參數為攻擊者提供了豐富的攻擊數據集。解決方法：如果將用戶看到的內容范圍限制為必需內容，限制關鍵數據的傳輸，并使數據查詢結構未知，那么攻擊者就很難對他們知道的參數進行爆密。

接下來還得檢測網站的各項功能以及APP功能是否存在邏輯漏洞，越權漏洞，水平垂直等等，我們SINE安全技術詳細的對每一個功能都測試很多遍，一次，兩次，多次的反復進行，在用戶重置密碼功能這里發(fā)現有漏洞，正常功能代碼設計是這樣的流程，首先會判斷用戶的賬號是否存在，以及下一步用戶的是否與數據庫里的一致，這里簡單地做了一下安全校驗，但是在獲取驗證碼的時候并沒有做安全校驗，導致可以post數據包，將為任意來獲取驗證碼，利用驗證碼來重置密碼。

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