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

1.注入漏洞。由于其普遍性和嚴重性，注入漏洞在Web0漏洞中始終排在位。常見的注入漏洞包括SQL、LDAP、OS命令、ORM和OGNL。用戶可以通過任何輸入點輸入構建的惡意代碼。如果應用程序沒有嚴格過濾用戶的輸入，一旦輸入的惡意代碼作為命令或查詢的一部分被發(fā)送到解析器，就可能導致注入漏洞。以SQL注入為例，是因為攻擊者通過瀏覽器或其他客戶端向網站參數中插入惡意SQL語句，而網站應用程序直接將惡意SQL語句帶入數據庫并執(zhí)行而不進行過濾，終導致通過數據庫獲取敏感信息或其他惡意操作。

中小企業(yè)，為什么受傷的總是我？
然而，雖然云存在有這樣那樣的問題，但企業(yè)上云已經成為眾多企業(yè)用戶的共識，也是未來發(fā)展的必然趨勢，越來越多的行業(yè)客戶也已經開始從傳統(tǒng) IDC 遷移上云。雖然目前絕大部分客戶都是將自有企業(yè)及業(yè)務系統(tǒng)等較輕量的架構上云，但從 CSDN 新出爐的《2017 中國軟件開發(fā)者》中，安全仍然是大多數企業(yè)在上云時面臨的頭號問題。

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