常見漏洞的防御措施整理

0x01 注入攻擊

風險說明

在以下情況下，應用程序易受攻擊：

應用程序不會驗證、過濾或清洗用戶提供的數據。

動態查詢或無上下文感知轉義的非參數化調用直接在解釋器中使用。

惡意數據在對象關系映射（ORM）搜索參數中用于提取額外的敏感記錄。

惡意數據被直接使用或連接。SQL或命令包含動態查詢、命令或存儲過程中的結構和惡意數據。

一些更常見的注入包括：SQL、 NoSQL、 OS命令、對象關系映射（ORM）、 LDAP和表達式語言（EL）或對象圖導航庫（OGNL）注入。這一概念在所有解析器中都是相同的。源代碼審查是檢測應用程序是否易受注入攻擊的最佳方法。強烈鼓勵針對所有參數、標題、 URL、 cookies 、 JSON、 SOAP和XML數據輸入的自動測試。組織可以在CI/CD管道中引入靜態（SAST）、動態（DAST）和交互式（IAST）應用程序安全測試工具，以在產品部署之前識別引入的注入缺陷

預防措施

防止注入需要將數據與命令和查詢分開：

推薦的選擇是使用安全的API，這樣可以避免完全使用解釋器、提供參數化接口或遷移到對象關系映射工具（ORM）。注意：即使參數化，如果PL/SQL或T-SQL將查詢和數據連接起來，或者使用 EXECUTE IMMEDIATE或exec （）執行惡意數據，則存儲過程仍然可以引入SQL注入。

使用肯定（positive）或 “白名單”服務器端輸入驗證。這并不是一種完美的防御，因為許多應用程序需要特殊字符，例如移動應用程序中的文本區域或API。

對于任何殘余的動態查詢，請使用該解釋器的特定轉義語法轉義特殊字符。注意：SQL結構（如表名、列名等）無法轉義，因此用戶提供的結構名是危險的。這是報表編寫軟件中的常見問題。

在查詢中使用LIMIT和其他SQL控件，以防止在SQL注入的情況下大量披露記錄。

0x02 文件上傳漏洞

系統運行時的防御

1、文件上傳的目錄設置為不可執行。只要wb容器無法解析該目錄下面的文件，即使攻擊者上傳了腳本文件，服務器本身也不會受到影響。

2、判斷文件類型。在判斷文件類型時，可以結合使用ME下yp、后綴檢查等方式。在文件類型檢查中，強烈推薦白名單方式，黑名單的方式已經無數次被證明是不可靠的。此外，對于圖片的處理，可以使用壓縮函數或者res立e函數，在處理圖片的同時破壞圖片中可能包含的HTML代碼。

3、使用隨機數改寫文件名和文件路徑。文件上傳如果要執行代碼，則需要用戶能夠訪問到這個文件。在某些環境中，用戶能上傳，但不能訪問。如果應用了隨機數改寫了文件名和路徑，將極大地增加攻擊的成本。再來就是像shel.php.rar.rar和cros sdomain.xml這種文件，將因為重命名而無法攻擊。

4、單獨設置文件服務器的域名。由于瀏覽器同源策略的關系，一系列客戶端攻擊將失效，比如上傳crossdomain.xml、上傳包含Javascript的XSS利用等問題將得到解決。

5、使用安全設備防御。文件上傳攻擊的本質就是將惡意文件或者腳本上傳到服務器，專業的安全設備防御，此類漏洞主要是通過對漏洞的上傳利用行為和惡意文件的上傳過程進行檢測。惡意文件千變萬化，隱藏手法也不斷推陳出新，對普通的系統管理員來說可以通過部署安全設備來幫助防御。

系統開發階段的防御

對文件上傳漏洞來說，最好能在客戶端和服務器端對用戶上傳的文件名和文件路徑等項目分別進行嚴格的檢查。客戶端的檢查雖然對技術較好的攻擊者來說可以借助工具繞過，但是這也可以阻擋一些基本的試探。

服務器端的檢查最好使用白名單過濾的方法，這樣能防止大小寫等方式的繞過，同時還需對%00截斷符進行檢測，對HTTP包頭的content-type也和上傳文件的大小也需要進行檢查。

系統維護階段

1、系統上線后運維人員應有較強的安全意思，積極使用多個安全檢測工具對系統進行安全掃描，及時發現潛在漏洞并修復。

2、定時查看系統日志，Wb服務器日志以發現入侵痕跡。定時關注系統所使用到的第三方插件的更新情況，如有新版本發布建議及時更新，如果第三方插件被爆有安全漏洞更應立即進行修補。

3、對于整個網站都是使用的開源代碼或者使用網上的框架搭建的網站來說，尤其要注意漏洞的自查和軟件版本及補丁的更新，上傳功能非必選可以直接刪除。除對系統自身的維護外，服務器應進行合理配置，非必選一般的目錄都應去掉執行權限，上傳目錄可配置為只讀。

0x03 認證會話管理

1、預防固定會話

一般來說，解決固定會話是相當容易的。最基本的建議就是：一旦用戶登錄成功以后，重寫SessionlD。

2、保護你的會話令牌

保護Cookie

Cookie有兩個很重要的屬性：secure和HttpOnly,設置好這兩個屬性對于保護你的Cookie至關重要。

提供ogoutI功能

上面介紹的是系統自動按照設定的時間使會話過期，一個好的應用程序應該提供一個功能，即用戶可以手動地使當前會話過期，這就是我們在幾乎所有網站上都看到的logout:按鈕。

3、多因素認證

對于很多重要的系統來說，如果只有密碼作為唯一的認證手段，從安全上看會略顯不足。因此為了增強安全性，大多數網上銀行和網上支付平臺都會采用雙因素認證或多因素認證。

支付寶提供的多種認證方式

除了支付密碼外，手機動態口令、數字證書、支付盾、第三方證書等都可用于用戶認證。

這些不同的認證手機可以互相結合，使得認證的過程更加安全。

4、身份認證設計完善

密碼長度和復雜性策略

密碼認證作為當前最流行的身份驗證方式，在安全方面最值得考慮的因素就是密碼的長度。一個強度高的密碼使得人工猜測或者暴力破解密碼的難度增加。

實現一個安全的密碼恢復策略

一個應用會提供密碼恢復功能。

重要的操作應通過HTTPS傳輸

對于重要的操作，如登錄、修改密碼等，一定要通過HTTPS進行傳輸。實現一個安全的密碼恢復策略

認證錯誤信息以及賬戶鎖定

不正確的認證錯誤信息可能會導致字典攻擊或者暴力破解，所以我們要盡可能地給出一個很普遍的錯誤信息。比如：登錄失敗，用戶名或密碼錯誤。

0x04 訪問控制

風險說明

訪問控制強制實施策略，使用戶無法在其預期權限之外進行操作。失敗的訪問控制通常會導致未經授權的信息泄露、修改或銷毀所有數據、或在用戶權限之外執行業務功能。常見的訪問控制脆弱點包括：

違反最小特權原則或默認拒絕原則，即訪問權限應該只授予特定能力、角色或用戶，但實際上任何人都可以訪問。

通過修改 URL （參數篡改或強制瀏覽）、內部應用程序狀態或 HTML 頁面，或使用修改 API 請求的攻擊工具來繞過訪問控制檢查。

通過提供唯一標識符（不安全的直接對象引用）允許查看或編輯其他人的帳戶

API沒有對POST、PUT 和DELETE強制執行訪問控制。

特權提升。在未登錄的情況下假扮用戶或以用戶身份登錄時充當管理員。

元數據操作，例如通過重放或篡改 JSONWeb 令牌 (JWT) 來訪問控制令牌，或操縱cookie 或隱藏字段以提升權限，或濫用 JWT 失效。

CORS 配置錯誤以致允許未授權或不可信的API訪問。

以未通過身份驗證的用戶身份強制瀏覽的通過身份驗證時才能看到的頁面或作為標準用戶身份訪問特權頁面。

防御措施

訪問控制只在受信服務器端代碼或無服務器API中有效，這樣攻擊者才無法修改訪問控制檢查或元數據。

除公有資源外，默認為 “拒絕訪問”。

使用一次性的訪問控制機制，并在整個應用程序中不斷重用它們，包括最小化跨源資源共享 (CORS) 的使用。

建立訪問控制模型以強制執行所有權記錄，而不是簡單接受用戶創建、讀取、更新或刪除的任何記錄。

特別的業務應用訪問限制需求應由領域模型強制執行。

禁用Web服務器目錄列表，并確保文件元數據（例如：.git）和備份文件不存在于Web的根目錄中。

在日志中記錄失敗的訪問控制，并在適當時向管理員告警（例如：重復故障）。

對API和控制器的訪問進行速率限制，以最大限度地降低自動化攻擊工具帶來的危害。

當用戶注銷后，服務器上的狀態會話標識符應失效。無狀態的JWT令牌應該是短暫的，以便讓攻擊者的攻擊機會窗口最小化。對于時間較長的JWT，強烈建議遵循OAuth標準來撤銷訪問。

0x05 加密

風險說明

首先要確認：對傳輸中數據和存儲數據都有哪些保護需求。例如，密碼、信用卡號、醫療記錄、個人信息和商業秘密需要額外保護，尤其是在這些數據屬于隱私保護法（如：歐盟GDPR) 或法規條例（如：金融數據保護標準PCI DSS)適用范圍的情況下。對于這些數據，要確定：

在傳輸數據過程中是否使用明文傳輸？這和傳輸協議有關，如：HTTP 、 SMTP 、經過TLS升級（如 STARTTLS ）的FTP。外部網絡流量是有害的。需要驗證所有的內部通信，如，負載平衡、 Web服務器或后端系統之間的流量。

無論是在默認情況下還是在舊的代碼中，是否還在使用任何舊的或脆弱的加密算法或傳輸協議？

是否使用默認加密密鑰、生成或重復使用脆弱的加密密鑰，或者是否缺少適當的密鑰管理或密鑰回轉？加密密鑰是否已經提交到源代碼存儲庫？

是否未執行強制加密，例如，是否缺少安全相關的HTTP （瀏覽器）指令或標頭？

接收到的服務器證書和信任鏈是否經過正確驗證？

初始化向量是否忽略，重用或生成的密碼操作模式是否不夠安全？是否正在使用不安全的操作模式，例如歐洲央行正在使用的操作模式？當認證加密更合適時是否使用加密？

在缺乏密碼基密鑰派生函數的情況下，是否將密碼用作加密密鑰？

隨機性是否用于并非旨在滿足加密要求的加密目的？即使選擇了正確的函數，它是否需要由開發人員播種，如果不需要，開發人員是否用缺乏足夠熵/不可預測性的種子覆蓋了內置的強大播種功能？

是否使用過時的散列函數，例如 MD5 或 SHA1，或者在散列函數需要加密時使用非加密散列函數？

是否在使用已棄用的加密填充方法，例如 PCKS number 1 v1.5？

加密的錯誤消息或側信道信息是否可以利用，例如使用填充預言機攻擊的形式？

預防措施

至少執行以下操作，并查閱參考資料：

對應用程序處理、存儲或傳輸的數據分類，并根據隱私法、監管要求或業務需求確定哪些數據是敏感的。

對于沒有必要存儲的敏感數據，應當盡快清除，或者通過PCI DSS標記化或攔截。未存儲的數據不能竊取。

確保加密存儲的所有敏感數據。

確保使用了最新的、強大的標準算法、協議和密鑰；并且密鑰管理到位。

確保加密傳輸過程中的數據，如使用安全協議（例如具有前向保密 (FS) 密碼的 TLS、服務器的密碼優先級和安全參數）。確保強制執行數據加密，如使用HTTP 嚴格安全傳輸協議 (HSTS) 等指令。

禁用緩存對包含敏感數據的響應。

根據數據分類應用實施所需的安全控制。

不要使用FTP 和SMTP 等傳統協議來傳輸敏感數據。

使用具有工作因子（延遲因子）的強自適應和加鹽散列函數存儲密碼，例如 Argon2、 scrypt、 bcrypt 或 PBKDF2。

必須選擇適合操作模式的初始化向量。對于大多數模式，可以使用CSPRNG （密碼安全偽隨機數生成器）。對于需要隨機數的模式，則初始化向量 (IV) 不需要使用CSPRNG。在所有情況下，對于一個固定密鑰，永遠不應該使用兩次IV。

始終使用經過驗證的加密，而不僅僅是加密。

密鑰應以加密方式隨機生成并作為字節數組存儲在內存中。如果使用密碼，則必須通過適當的密碼基密鑰派生函數將其轉換為密鑰。

確保在適當的地方使用加密隨機性，并且沒有以可預測的方式或低熵進行播種。大多數現代 API 不需要開發人員為 CSPRNG 設置種子以獲得安全性。

避免使用的已廢棄的加密函數和填充方案，例如 MD5、 SHA1、 PKCS number 1 v1.5。

單獨驗證每個安全配置項的有效性。

0x06 框架漏洞

https://zhuanlan.zhihu.com/p/353034640

0x07 DDOS

防御方法

1、采用高性能的網絡設備

首先要保證網絡設備不能成為瓶頸，因此選擇路由器、交換機、硬件防火墻等設備的時候要盡量選用知名度高、口碑好的產品。再就是假如和網絡提供商有特殊關系或協議的話就更好了，當大量攻擊發生的時候請他們在網絡接點處做一下流量限制來對抗某些種類的DDoS攻擊是非常有效的。

2、盡量避免NAT的使用

無論是路由器還是硬件防護墻設備要盡量避免采用網絡地址轉換NAT的使用，因為采用此技術會較大降低網絡通信能力，其實原因很簡單，因為NAT需要對地址來回轉換，轉換過程中需要對網絡包的校驗和進行計算，因此浪費了很多CPU的時間，但有些時候必須使用NAT,那就沒有好辦法了。

3、充足的網絡帶寬保證

網絡帶寬直接決定了能抗受攻擊的能力，假若僅僅有10M帶寬的話，無論采取什么措施都很難對抗現在的SYNFIood攻擊，當前至少要選擇100M的共享帶寬，最好的當然是掛在1000M的主干上了。但需要注意的是，主機上的網卡是1000M的并不意味著它的網絡帶寬就是千兆的，若把它接在100M的交換機上，它的實際帶寬不會超過100M,再就是接在100M的帶寬上也不等于就有了百兆的帶寬，因為網絡服務商很可能會在交換機上限制實際帶寬為10M,這點一定要搞清楚。

4、升級主機服務器硬件

在有網絡帶寬保證的前提下，請盡量提升硬件配置，要有效對抗每秒10萬個SYN攻擊包，服務器的配置至少應該為：

P42.4G/DDR512M/SCS1-HD,起關鍵作用的主要是CPU和內存，若有志強雙CPU的話就用它吧，內存一定要選擇DDR的高速內存，硬盤要盡量選擇SCS的，別只貪DE價格不貴量還足的便宜，否則會付出高昂的性能代價，再就是網卡一定要選用3COM或Intel等名牌的，若是Realtekl的還是用在自己的PC上吧。

5、把網站做成靜態頁面或者偽靜態

大量事實證明，把網站盡可能做成靜態頁面，不僅能大大提高抗攻擊能力，而且還給黑客入侵帶來不少麻煩，至少到現在為止關于HTML的溢出還沒出現，看看吧！新浪、搜狐、網易等門戶網站主要都是靜態頁面，若你非需要動態腳本調用，那就把它弄到另外一臺單獨主機去，免的遭受攻擊時連累主服務器，當然，適當放一些不做數據庫調用腳本還是可以的，此外，最好在需要調用數據庫的腳本中拒絕使用代理的訪問，因為經驗表明使用代理訪問你網站的80%屬于惡意行為。

6、增強操作系統的TCP/IP棧

Win2000和Win2003作為服務器操作系統，本身就具備一定的抵抗DDoS攻擊的能力，只是默認狀態下沒有開啟而已，

若開啟的話可抵擋約10000個SYN攻擊包，若沒有開啟則僅能抵御數百個，具體怎么開啟，可以看看微軟的文章吧！《強化TCPP堆棧安全》

7、安裝專業抗DDOS防火墻

8、HTTP請求的攔截

如果惡意請求有特征，對付起來很簡單：直接攔截它就行了。

HTTP請求的特征一般有兩種：P地址和User Agent字段。比如，惡意請求都是從某個IP段發出的，那么把這個IP段封掉就行了。或者，它們的User Agent字段有特征（包含某個特定的詞語），那就把帶有這個詞語的請求攔截。

9、備份網站

你要有一個備份網站，或者最低限度有一個臨時主頁。生產服務器萬一下線了，可以立刻切換到備份網站，不至于毫無辦法。

備份網站不一定是全功能的，如果能做到全靜態瀏覽，就能滿足需求。最低限度應該可以顯示公告，告訴用戶，網站出了問題，正在全力搶修。

這種臨時主頁建議放到Github Pages或者Netlify,它們的帶寬大，可以應對攻擊，而且都支持綁定域名，還能從源碼自動構建。

10、部署CDN

CDN指的是網站的靜態內容分發到多個服務器，用戶就近訪問，提高速度。因此，CDN也是帶寬擴容的一種方法，可以用來防御DDOS攻擊。

網站內容存放在源服務器，CDN上面是內容的緩存。用戶只允許訪問CDN,如果內容不在CDN上，CDN再向源服務器發出請求。這樣的話，只要CDN夠大，就可以抵御很大的攻擊。不過，這種方法有一個前提，網站的大部分內容必須可以靜態緩存。對于動態內容為主的網站（比如論壇），就要想別的辦法，盡量減少用戶對動態數據的請求；本質就是自己搭建一個微型CDN。各大云服務商提供的高防P,背后也是這樣做的：網站域名指向高防P,它提供一個緩沖層，清洗流量，并對源服務器的內容進行緩存。

這里有一個關鍵點，一旦上了CDN,千萬不要泄露源服務器的P地址，否則攻擊者可以繞過CDN直接攻擊源服務器，前面的努力都白費。搜一下"繞過CDN獲取真實P地址"，你就會知道國內的黑產行業有多猖獗。

11、其他防御措施

以上幾條對抗DDoS建議，適合絕大多數擁有自己主機的用戶，但假如采取以上措施后仍然不能解決DDoS問題，就有些麻煩了，可能需要更多投資，增加服務器數量并采用DNS輪巡或負載均衡技術，甚至需要購買七層交換機設備，從而使得抗DDoS攻擊能力成倍提高，只要投資足夠深入。

0x08 安全配置

風險說明

您的應用程序可能受到攻擊，如果應用程序是：

應用程序棧的任何部分缺少適當的安全加固，或者云服務的權限配置錯誤。

應用程序啟用或安裝了不必要的功能（例如：不必要的端口、服務、網頁、帳戶或權限）。

默認帳戶和密碼仍然可用且沒有更改。

錯誤處理機制向用戶紕漏堆棧信息或其他大量錯誤信息。

對于升級的系統，最新的安全特性被禁用或未安全配置。

應用程序服務器、應用程序框架（如：Struts、 Spring、 ASP.NET）、庫文件、數據庫等沒有進行安全配置。