一、漏洞級別
高級別漏洞:大部分遠程和本地管理員權限漏洞
中級別漏洞:大部分普通用戶權限、權限提升、讀懂受限文件、遠程和本杜漏洞、拒絕服務漏洞
低級別漏洞:大部分遠程非授權文件存取、口令恢復、欺騙、信息泄露漏洞?
二、漏洞掃描的原理
是通過掃描目標系統的網絡端口和服務,然后嘗試利用已知的漏洞來獲取對目標系統的未授權訪問或執行惡意操作。?
三、漏掃和滲透的區別
漏洞掃描:主要目的是識別目標系統中存在的已知漏洞,并提供有關這些漏洞的信息。
滲透測試:旨在模擬真實攻擊場景,評估目標系統的安全性,并嘗試利用已知和未知漏洞來獲取對系統的未授權訪問。
配置核查:是指對系統、網絡或應用程序的配置進行檢查和評估,以確保其符合安全要求和最佳實踐。配置核查的目的是識別和糾正可能導致潛在風險和漏洞的不安全設置。
四、常見漏洞修復建議
(1)SQL注入
????????漏洞描述: Web程序中對于用戶提交的參數未做過濾直接拼接到SQL語句中執行,導致參數中的特殊字符破壞了SQL語句原有邏輯,攻擊者可以利用該漏洞執行任意SQL語句,如查詢數據、下載數據、寫入webshell、執行系統命令以及繞過登錄限制等。
修復建議: ? ? ?
????????代碼層最佳防御sql漏洞方案:使用預編譯sql語句查詢和綁定變量。
- 使用預編譯語句,使用PDO需要注意不要將變量直接拼接到PDO語句中。所有的查詢語句都使用數據庫提供的參數化查詢接口,參數化的語句使用參數而不是將用戶輸入變量嵌入到SQL語句中。當前幾乎所有的數據庫系統都提供了參數化SQL語句執行接口,使用此接口可以非常有效的防止SQL注入攻擊。 ??
- 確認每種數據的類型,比如數字型的數據就必須是數字,數據庫中的存儲字段必須對應為int型。
- 數據長度應該嚴格規定,能在一定程度上防止比較長的SQL注入語句無法正確執行。
- 網站每個數據層的編碼統一,建議全部使用UTF-8編碼,上下層編碼不一致有可能導致一些過濾模型被繞過。
- 嚴格限制網站用戶的數據庫的操作權限,給此用戶提供僅僅能夠滿足其工作的權限,從而最大限度的減少注入攻擊對數據庫的危害。
- 避免網站顯示SQL錯誤信息,比如類型錯誤、字段不匹配等,防止攻擊者利用這些錯誤信息進行一些判斷。
- 過濾危險字符,例如:采用正則表達式匹配union、sleep、and、select、load_file等關鍵字,如果匹配到則終止運行。
(2)XSS 漏洞描述:
(1)反射型XSS:
????????Web程序代碼中對用戶提交的參數未做過濾或過濾不嚴,導致參數中的特殊字符破壞了HTML頁面的原有邏輯,攻擊者可以利用該漏洞執行惡意HTML/JS代碼、構造蠕蟲、篡改頁面實施釣魚攻擊、以及誘導用戶再次登錄,然后獲取其登錄憑證等。 ? ? ?
(2)存儲型XSS:
????????XSS攻擊對Web服務器本身雖無直接危害,但是它借助網站進行傳播,對網站用戶進行攻擊,竊取網站用戶賬號身份信息等,從而也會對網站產生較嚴重的威脅。
修復建議:
????????XSS漏洞本質上是一種html注入,也就是將html代碼注入到網頁中。那么其防御的根本就是在將用戶提交的代碼顯示到頁面上時做好一系列的過濾與轉義。
- 過濾輸入的數據,對例如:“ ‘ ”,“ “ ”,” < “,” > “,” on* “,script、iframe等危險字符進行嚴格的檢查。這里的輸入不僅僅是用戶可以直接交互的輸入接口,也包括HTTP請求中的Cookie中的變量,HTTP請求頭部中的變量等。
- 不僅驗證數據的類型,還要驗證其格式、長度、范圍和內容。
- 不僅在客戶端做數據的驗證與過濾,關鍵的過濾步驟在服務端進行。
- 對輸出到頁面的數據進行相應的編碼轉換,如HTML實體編碼、JS編碼等。對輸出的數據也要檢查,數據庫里的值有可能會在一個大網站的多處都有輸出,即使在輸入做了編碼等操作,在各處的輸出點時也要進行檢查。
(3)CSRF 漏洞描述:
????????CSRF是跨站請求偽造,不攻擊網站服務器,而是冒充用戶在站內的正常操作。通常由于服務端沒有對請求頭做嚴格過濾引起的。CSRF會造成密碼重置,用戶偽造等問題,可能引發嚴重后果。絕大多數網站是通過 cookie 等方式辨識用戶身份,再予以授權的。
修復建議:
- 驗證請求的Referer是否來自本網站,但可被繞過。
- 在請求中加入不可偽造的token,并在服務端驗證token是否一致或正確,不正確則丟棄拒絕服務。
(4)SSRF
????????漏洞描述: SSRF(Server-Side Request Forgery,服務器端請求偽造):通俗的來說就是我們可以偽造服務器端發起的請求,從而獲取客戶端所不能得到的數據。SSRF漏洞形成的原因主要是服務器端所提供的接口中包含了所要請求的內容的URL參數,并且未對客戶端所傳輸過來的URL參數進行過濾,可造成以下危害:
1.可以對外網、服務器所在內網、本地進行端口掃描,獲取一些服務的banner信息;
2.攻擊運行在內網或本地的應用程序(比如溢出);
3.對內網Web應用進行指紋識別,通過訪問默認文件實現;
4.攻擊內外網的Web應用,主要是使用Get參數就可以實現的攻擊(比如Struts2漏洞利用,SQL注入等);
5.利用File協議讀取本地文件
修復建議:
- 禁用不需要的協議,只允許HTTP和HTTPS請求,可以防止類似于file://, gopher://, ftp:// 等引起的問題。
- 白名單的方式限制訪問的目標地址,禁止對內網發起請求
- 過濾或屏蔽請求返回的詳細信息,驗證遠程服務器對請求的響應是比較容易的方法。如果web應用是去獲取某一種類型的文件。那么在把返回結果展示給用戶之前先驗證返回的信息是否符合標準。 ?
- 驗證請求的文件格式?
- 禁止跳轉 ?
- 限制請求的端口為http常用的端口,比如 80、443、8080、8000等 ?
- 統一錯誤信息,避免用戶可以根據錯誤信息來判斷遠端服務器的端口狀態
(5)URL 跳轉
????????漏洞描述: 有的Web 應用程序中使用URL參數中的地址作為跳轉鏈接的功能 ,攻擊者可實施釣魚、惡意網站跳轉等攻擊。
修復建議:
- 在進行頁面跳轉前校驗傳入的URL是否為可信域名。
- 白名單規定跳轉鏈接。
(6)未授權訪問
????????漏洞描述: 由于沒有對網站敏感頁面進行登錄狀態、訪問權限的檢查,導致攻擊者可未授權訪問,獲取敏感信息及進行未授權操作。
修復建議:
- 頁面進行嚴格的訪問權限的控制以及對訪問角色進行權限檢查。
- 可以使用session對用戶的身份進行判斷和控制。?
(7)文件上傳
????????漏洞描述:
????????文件上傳漏洞通常由于代碼中對文件上傳功能所上傳的文件過濾不嚴或web服務器相關解析漏洞未修復而造成的,如果文件上傳功能代碼沒有嚴格限制和驗證用戶上傳的文件后綴、類型等,攻擊者可通過文件上傳點上傳任意文件,包括網站后門文件(webshell)控制整個網站。
修復建議:
- 對上傳文件類型進行驗證,除在前端驗證外在后端依然要做驗證,后端可以進行擴展名檢測,重命名文件,MIME類型檢測以及限制上傳文件的大小等限制來防御,或是將上傳的文件其他文件存儲服務器中。
- 嚴格限制和校驗上傳的文件,禁止上傳惡意代碼的文件。同時限制相關上傳文件目錄的執行權限,防止木馬執行。
- 對上傳文件格式進行嚴格校驗,防止上傳惡意腳本文件。
- 嚴格限制上傳的文件路徑。?
- 文件擴展名在服務端白名單校驗。
- 文件內容服務端校驗。
- 上傳文件重命名。
- 隱藏上傳文件路徑。
(8)目錄穿越/目錄遍歷
????????漏洞描述: 文件下載或獲取文件顯示內容頁面由于未對傳入的文件名進行過濾,利用路徑回溯符../跳出程序本身的限制目錄,來下載或顯示任意文件。
修復建議:
- 對傳入的文件名參數進行過濾,并且判斷是否是允許獲取的文件類型,過濾回溯符../?
(9)文件包含
????????漏洞描述: 本地文件包含是指程序在處理包含文件的時候沒有嚴格控制。利用這個漏洞,攻擊者可以先把上傳的文件、網站日志文件等作為代碼執行或直接顯示出來,或者包含遠程服務器上的惡意文件,進而獲取到服務器權限。
修復建議:
- 嚴格檢查變量是否已經初始化。
- 對所有輸入提交可能包含的文件地址,包括服務器本地文件及遠程文件,進行嚴格的檢查,參數中不允許出現./和../等目錄跳轉符。
- 嚴格檢查文件包含函數中的參數是否外界可控。?
(10)越權訪問
????????漏洞描述: 由于沒有對用戶訪問角色的權限進行嚴格的檢查及限制,導致當前賬號可對其他賬號進行相關操作,如查看、修改等。對低權限對高權限賬戶的操作為縱向越權,相同權限賬戶之間的操作成為橫向越權也稱水平越權。
修復建議:
- 對用戶訪問角色的權限進行嚴格的檢查及限制。
- 在一些操作時可以使用session對用戶的身份進行判斷和控制。?
(11)敏感信息泄露
???????? 漏洞描述: 在頁面中或者返回的響應包中泄露了敏感信息,通過這些信息,給攻擊者滲透提供了非常多的有用信息。
修復建議:
- 如果是探針或測試頁面等無用的程序建議刪除,或者修改成難以猜解的名字。
- 不影響業務或功能的情況下刪除或禁止訪問泄露敏感信息頁面。
- 在服務器端對相關敏感信息進行模糊化處理。
- 對服務器端返回的數據進行嚴格的檢查,滿足查詢數據與頁面顯示數據一致。?
?(12)明文傳輸
????????漏洞描述: 用戶登錄過程中使用明文傳輸用戶登錄信息,若用戶遭受中間人攻擊時,攻擊者可直接獲取該用戶登錄賬戶,從而進行進一步滲透。
修復建議:
- 用戶登錄信息使用加密傳輸,如密碼在傳輸前使用安全的算法加密后傳輸,可采用的算法包括:不可逆hash算法加鹽(4位及以上隨機數,由服務器端產生);安全對稱加密算法,如AES(128、192、256位),且必須保證客戶端密鑰安全,不可被破解或讀出;非對稱加密算法,如RSA(不低于1024位)、SM2等。
- 使用https來保證傳輸的安全。
(13)命令執行
????????漏洞描述: 命令或代碼執行漏洞是指代碼未對用戶可控參數做過濾,導致直接帶入執行命令和代碼,通過漏洞執行惡意構造的語句,執行任意命令或代碼。攻擊者可在服務器上執行任意命令,讀寫文件操作等,危害巨大。
修復建議:
- 嚴格過濾用戶輸入的數據,禁止執行非預期系統命令。
- 減少或不使用代碼或命令執行函數。
- 客戶端提交的變量在放入函數前進行檢測。
- 減少或不使用危險函數。?
(14)暴力破解
???????? 漏洞描述: 由于沒有對登錄頁面進行相關的人機驗證機制,如無驗證碼、有驗證碼但可重復利用以及無登錄錯誤次數限制等,導致攻擊者可通過暴力破解獲取用戶登錄賬號和密碼。
修復建議:
- 如果用戶登錄次數超過設置的閾值,則鎖定帳號(有惡意登錄鎖定帳號的風險)。
- 如果某個 IP登錄次數超過設置的閾值,則鎖定IP。
- 增加人機驗證機制。
- 驗證碼必須在服務器端進行校驗,客戶端的一切校驗都是不安全的。?
(15)弱口令
????????漏洞描述: 由于網站用戶帳號存在弱口令,導致攻擊者通過弱口令可輕松登錄到網站中,從而進行下一步的攻擊,如上傳webshell,獲取敏感數據。另外攻擊者利用弱口令登錄網站管理后臺,可執行任意管理員的操作。
修復建議:
- 強制用戶首次登錄時修改默認口令,或是使用用戶自定義初始密碼的策略。
- 完善密碼策略,信息安全最佳實踐的密碼策略為8位(包括)以上字符,包含數字、大小寫字母、特殊字符中的至少3種。增加人機驗證機制。
- 增加人機驗證機制,限制IP訪問次數。?
(16)短信/郵件轟炸
????????漏洞描述: 由于沒有對短信或者郵件發送次數進行限制,導致可無限次發送短信或郵件給用戶,從而造成短信轟炸,進而可能被大量用戶投訴,從而影響公司聲譽。
修復建議:
- 在服務器限制發送短信或郵件的頻率,如同一賬號1分鐘只能發送1次短信或郵件,一天只能發送3次。?
?