風(fēng)險(xiǎn)說(shuō)明
在以下情況下，應(yīng)用程序易受攻擊：
應(yīng)用程序不會(huì)驗(yàn)證、過(guò)濾或清洗用戶提供的數(shù)據(jù)。
動(dòng)態(tài)查詢或無(wú)上下文感知轉(zhuǎn)義的非參數(shù)化調(diào)用直接在解釋器中使用。
惡意數(shù)據(jù)在對(duì)象關(guān)系映射（ORM）搜索參數(shù)中用于提取額外的敏感記錄。
惡意數(shù)據(jù)被直接使用或連接。SQL或命令包含動(dòng)態(tài)查詢、命令或存儲(chǔ)過(guò)程中的結(jié)構(gòu)和惡意數(shù)據(jù)。
一些更常見的注入包括：SQL、 NoSQL、 OS命令、 對(duì)象關(guān)系映射 （ORM） 、 LDAP和表達(dá)式 語(yǔ)言 （EL） 或?qū)ο髨D導(dǎo)航庫(kù) （OGNL） 注入。這一概念在所有解析器中都是相同的。源代碼審查是 檢測(cè)應(yīng)用程序是否易受注入攻擊的最佳方法 。強(qiáng)烈鼓勵(lì)針對(duì)所有參數(shù) 、 標(biāo)題 、 URL、 cookies 、 JSON、 SOAP和XML數(shù)據(jù)輸入的自動(dòng)測(cè)試。組織可以在CI/CD管道中引入靜態(tài) （SAST） 、 動(dòng)態(tài) （DAST） 和交互式 （IAST） 應(yīng)用程序安全測(cè)試工具， 以在產(chǎn)品部署之前識(shí)別引入的注入缺陷
預(yù)防措施
防止注入需要將數(shù)據(jù)與命令和查詢分開：
推薦的選擇是使用安全的API， 這樣可以避免完全使用解釋器、 提供參數(shù)化接口或遷移到對(duì)象關(guān)系 映射工具 （ORM） 。注意：即使參數(shù)化， 如果PL/SQL或T-SQL將查詢和數(shù)據(jù)連接起來(lái)， 或者使用 EXECUTE IMMEDIATE或exec （） 執(zhí)行惡意數(shù)據(jù)， 則存儲(chǔ)過(guò)程仍然可以引入SQL注入。
使用肯定 （positive） 或 “白名單”服務(wù)器端輸入驗(yàn)證。這并不是一種完美的防御， 因?yàn)樵S多應(yīng)用 程序需要特殊字符， 例如移動(dòng)應(yīng)用程序中的文本區(qū)域或API。
對(duì)于任何殘余的動(dòng)態(tài)查詢， 請(qǐng)使用該解釋器的特定轉(zhuǎn)義語(yǔ)法轉(zhuǎn)義特殊字符。注意：SQL結(jié)構(gòu) （如表 名、 列名等） 無(wú)法轉(zhuǎn)義， 因此用戶提供的結(jié)構(gòu)名是危險(xiǎn)的。這是報(bào)表編寫軟件中的常見問題。
在查詢中使用LIMIT和其他SQL控件， 以防止在SQL注入的情況下大量披露記錄。
系統(tǒng)運(yùn)行時(shí)的防御
1、文件上傳的目錄設(shè)置為不可執(zhí)行。只要wb容器無(wú)法解析該目錄下面的文件，即使攻擊者上傳了腳本文件，服務(wù)器本身也不會(huì)受到影響。
2、判斷文件類型。在判斷文件類型時(shí)，可以結(jié)合使用ME下yp、后綴檢查等方式。在文件類型檢查中，強(qiáng)烈推薦白名單方式，黑名單的方式已經(jīng)無(wú)數(shù)次被證明是不可靠的。此外，對(duì)于圖片的處理，可以使用壓縮函數(shù)或者res立e函數(shù)，在處理圖片的同時(shí)破壞圖片中可能包含的HTML代碼。
3、使用隨機(jī)數(shù)改寫文件名和文件路徑。文件上傳如果要執(zhí)行代碼，則需要用戶能夠訪問到這個(gè)文件。在某些環(huán)境中，用戶能上傳，但不能訪問。如果應(yīng)用了隨機(jī)數(shù)改寫了文件名和路徑，將極大地增加攻擊的成本。再來(lái)就是像shel.php.rar.rar和crossdomain.xml這種文件，將因?yàn)橹孛鵁o(wú)法攻擊。
4、單獨(dú)設(shè)置文件服務(wù)器的域名。由于瀏覽器同源策略的關(guān)系，一系列客戶端攻擊將失效，比如上傳crossdomain.xml、上傳包含Javascript的XSS利用等問題將得到解決。
5、使用安全設(shè)備防御。文件上傳攻擊的本質(zhì)就是將惡意文件或者腳本上傳到服務(wù)器，專業(yè)的安全設(shè)備防御，此類漏洞主要是通過(guò)對(duì)漏洞的上傳利用行為和惡意文件的上傳過(guò)程進(jìn)行檢測(cè)。惡意文件千變?nèi)f化，隱藏手法也不斷推陳出新，對(duì)普通的系統(tǒng)管理員來(lái)說(shuō)可以通過(guò)部署安全設(shè)備來(lái)幫助防御。
系統(tǒng)開發(fā)階段的防御
對(duì)文件上傳漏洞來(lái)說(shuō)，最好能在客戶端和服務(wù)器端對(duì)用戶上傳的文件名和文件路徑等項(xiàng)目分別進(jìn)行嚴(yán)格的檢查?？蛻舳说臋z查雖然對(duì)技術(shù)較好的攻擊者來(lái)說(shuō)可以借助工具繞過(guò)，但是這也可以阻擋一些基本的試探。
服務(wù)器端的檢查最好使用白名單過(guò)濾的方法，這樣能防止大小寫等方式的繞過(guò)，同時(shí)還需對(duì)%00截?cái)喾M(jìn)行檢測(cè)，對(duì)HTTP包頭的content-type也和上傳文件的大小也需要進(jìn)行檢查。
系統(tǒng)維護(hù)階段
1、系統(tǒng)上線后運(yùn)維人員應(yīng)有較強(qiáng)的安全意思，積極使用多個(gè)安全檢測(cè)工具對(duì)系統(tǒng)進(jìn)行安全掃描，及時(shí)發(fā)現(xiàn)潛在漏洞并修復(fù)。
2、定時(shí)查看系統(tǒng)日志，Wb服務(wù)器日志以發(fā)現(xiàn)入侵痕跡。定時(shí)關(guān)注系統(tǒng)所使用到的第三方插件的更新情況，如有新版本發(fā)布建議及時(shí)更新，如果第三方插件被爆有安全漏洞更應(yīng)立即進(jìn)行修補(bǔ)。
3、對(duì)于整個(gè)網(wǎng)站都是使用的開源代碼或者使用網(wǎng)上的框架搭建的網(wǎng)站來(lái)說(shuō)，尤其要注意漏洞的自查和軟件版本及補(bǔ)丁的更新，上傳功能非必選可以直接刪除。除對(duì)系統(tǒng)自身的維護(hù)外，服務(wù)器應(yīng)進(jìn)行合理配置，非必選一般的目錄都應(yīng)去掉執(zhí)行權(quán)限，上傳目錄可配置為只讀。
0x03 認(rèn)證會(huì)話管理
1、預(yù)防固定會(huì)話
一般來(lái)說(shuō)，解決固定會(huì)話是相當(dāng)容易的。最基本的建議就是：一旦用戶登錄成功以后，重寫SessionlD。
2、保護(hù)你的會(huì)話令牌
保護(hù)Cookie
Cookie有兩個(gè)很重要的屬性：secure和HttpOnly,設(shè)置好這兩個(gè)屬性對(duì)于保護(hù)你的Cookie至關(guān)重要。
提供ogoutI功能
上面介紹的是系統(tǒng)自動(dòng)按照設(shè)定的時(shí)間使會(huì)話過(guò)期，一個(gè)好的應(yīng)用程序應(yīng)該提供一個(gè)功能，即用戶可以手動(dòng)地使當(dāng)前會(huì)話過(guò)期，這就是我們?cè)趲缀跛芯W(wǎng)站上都看到的logout:按鈕。
3、多因素認(rèn)證
對(duì)于很多重要的系統(tǒng)來(lái)說(shuō)，如果只有密碼作為唯一的認(rèn)證手段，從安全上看會(huì)略顯不足。因此為了增強(qiáng)安全性，大多數(shù)網(wǎng)上銀行和網(wǎng)上支付平臺(tái)都會(huì)采用雙因素認(rèn)證或多因素認(rèn)證。
支付寶提供的多種認(rèn)證方式
除了支付密碼外，手機(jī)動(dòng)態(tài)口令、數(shù)字證書、支付盾、第三方證書等都可用于用戶認(rèn)證。
這些不同的認(rèn)證手機(jī)可以互相結(jié)合，使得認(rèn)證的過(guò)程更加安全。
0x04 訪問控制
風(fēng)險(xiǎn)說(shuō)明
訪問控制強(qiáng)制實(shí)施策略，使用戶無(wú)法在其預(yù)期權(quán)限之外進(jìn)行操作。失敗的訪問控制通常會(huì)導(dǎo)致未經(jīng)授權(quán)的信息泄露、修改或銷毀所有數(shù)據(jù)、或在用戶權(quán)限之外執(zhí)行業(yè)務(wù)功能。常見的訪問控制脆弱點(diǎn)包括：
違反最小特權(quán)原則或默認(rèn)拒絕原則，即訪問權(quán)限應(yīng)該只授予特定能力、角色或用戶，但實(shí)際上任何人都可 以訪問。
通過(guò)修改 URL （參數(shù)篡改或強(qiáng)制瀏覽）、內(nèi)部應(yīng)用程序狀態(tài)或 HTML 頁(yè)面，或使用修改 API 請(qǐng)求的攻擊 工具來(lái)繞過(guò)訪問控制檢查。
通過(guò)提供唯一標(biāo)識(shí)符（不安全的直接對(duì)象引用）允許查看或編輯其他人的帳戶
API沒有對(duì)POST、PUT 和DELETE強(qiáng)制執(zhí)行訪問控制。
特權(quán)提升。在未登錄的情況下假扮用戶或以用戶身份登錄時(shí)充當(dāng)管理員。
元數(shù)據(jù)操作，例如通過(guò)重放或篡改 JSONWeb 令牌 (JWT) 來(lái)訪問控制令牌，或操縱cookie 或隱藏字段以 提升權(quán)限，或?yàn)E用 JWT 失效。
CORS 配置錯(cuò)誤以致允許未授權(quán)或不可信的API訪問。
以未通過(guò)身份驗(yàn)證的用戶身份強(qiáng)制瀏覽的通過(guò)身份驗(yàn)證時(shí)才能看到的頁(yè)面或作為標(biāo)準(zhǔn)用戶身份訪問特權(quán)頁(yè)面。
訪問控制只在受信服務(wù)器端代碼或無(wú)服務(wù)器API中有效，這樣攻擊者才無(wú)法修改訪問控制檢查或元數(shù)據(jù)。
除公有資源外，默認(rèn)為 “拒絕訪問”。
使用一次性的訪問控制機(jī)制，并在整個(gè)應(yīng)用程序中不斷重用它們， 包括最小化跨源資源共享 (CORS) 的使 用。
建立訪問控制模型以強(qiáng)制執(zhí)行所有權(quán)記錄，而不是簡(jiǎn)單接受用戶創(chuàng)建、 讀取、 更新或刪除的任何記錄。
特別的業(yè)務(wù)應(yīng)用訪問限制需求應(yīng)由領(lǐng)域模型強(qiáng)制執(zhí)行。
禁用Web服務(wù)器目錄列表，并確保文件元數(shù)據(jù)（例如：.git） 和備份文件不存在于Web的根目錄中。
在日志中記錄失敗的訪問控制，并在適當(dāng)時(shí)向管理員告警 （例如：重復(fù)故障）。
對(duì)API和控制器的訪問進(jìn)行速率限制， 以最大限度地降低自動(dòng)化攻擊工具帶來(lái)的危害。
當(dāng)用戶注銷后，服務(wù)器上的狀態(tài)會(huì)話標(biāo)識(shí)符應(yīng)失效。無(wú)狀態(tài)的JWT令牌應(yīng)該是短暫的，以便讓攻擊者的攻 擊機(jī)會(huì)窗口最小化。對(duì)于時(shí)間較長(zhǎng)的JWT， 強(qiáng)烈建議遵循OAuth標(biāo)準(zhǔn)來(lái)撤銷訪問。
風(fēng)險(xiǎn)說(shuō)明
首先要確認(rèn)：對(duì)傳輸中數(shù)據(jù)和存儲(chǔ)數(shù)據(jù)都有哪些保護(hù)需求。例如， 密碼、 信用卡號(hào)、 醫(yī)療記錄、 個(gè)人信 息和商業(yè)秘密需要額外保護(hù)， 尤其是在這些數(shù)據(jù)屬于隱私保護(hù)法 （如：歐盟GDPR) 或法規(guī)條例 （如：金融數(shù)據(jù)保護(hù)標(biāo)準(zhǔn)PCI DSS)適用范圍的情況下。對(duì)于這些數(shù)據(jù)， 要確定：
在傳輸數(shù)據(jù)過(guò)程中是否使用明文傳輸？這和傳輸協(xié)議有關(guān)， 如：HTTP 、 SMTP 、 經(jīng)過(guò)TLS升級(jí) （如 STARTTLS ） 的FTP。外部網(wǎng)絡(luò)流量是有害的。需要驗(yàn)證所有的內(nèi)部通信， 如， 負(fù)載平衡、 Web服務(wù)器或 后端系統(tǒng)之間的流量。
無(wú)論是在默認(rèn)情況下還是在舊的代碼中， 是否還在使用任何舊的或脆弱的加密算法或傳輸協(xié)議？
是否使用默認(rèn)加密密鑰、 生成或重復(fù)使用脆弱的加密密鑰， 或者是否缺少適當(dāng)?shù)拿荑€管理或密鑰回轉(zhuǎn)？加 密密鑰是否已經(jīng)提交到源代碼存儲(chǔ)庫(kù)？
是否未執(zhí)行強(qiáng)制加密， 例如， 是否缺少安全相關(guān)的HTTP （瀏覽器） 指令或標(biāo)頭？
接收到的服務(wù)器證書和信任鏈?zhǔn)欠窠?jīng)過(guò)正確驗(yàn)證？
初始化向量是否忽略， 重用或生成的密碼操作模式是否不夠安全？是否正在使用不安全的操作模式， 例如 歐洲央行正在使用的操作模式？當(dāng)認(rèn)證加密更合適時(shí)是否使用加密？
在缺乏密碼基密鑰派生函數(shù)的情況下， 是否將密碼用作加密密鑰？
隨機(jī)性是否用于并非旨在滿足加密要求的加密目的？即使選擇了正確的函數(shù)， 它是否需要由開發(fā)人員播種， 如果不需要， 開發(fā)人員是否用缺乏足夠熵/不可預(yù)測(cè)性的種子覆蓋了內(nèi)置的強(qiáng)大播種功能？
是否使用過(guò)時(shí)的散列函數(shù)， 例如 MD5 或 SHA1， 或者在散列函數(shù)需要加密時(shí)使用非加密散列函數(shù)？
是否在使用已棄用的加密填充方法， 例如 PCKS number 1 v1.5？
加密的錯(cuò)誤消息或側(cè)信道信息是否可以利用， 例如使用填充預(yù)言機(jī)攻擊的形式？
至少執(zhí)行以下操作， 并查閱參考資料：
對(duì)應(yīng)用程序處理、 存儲(chǔ)或傳輸?shù)臄?shù)據(jù)分類， 并根據(jù)隱私法、 監(jiān)管要求或業(yè)務(wù)需求確定哪些數(shù)據(jù)是敏感的。
對(duì)于沒有必要存儲(chǔ)的敏感數(shù)據(jù)， 應(yīng)當(dāng)盡快清除， 或者通過(guò)PCI DSS標(biāo)記化或攔截。未存儲(chǔ)的數(shù)據(jù)不能竊取。
確保加密存儲(chǔ)的所有敏感數(shù)據(jù)。
確保使用了最新的、 強(qiáng)大的標(biāo)準(zhǔn)算法、 協(xié)議和密鑰；并且密鑰管理到位。
確保加密傳輸過(guò)程中的數(shù)據(jù)， 如使用安全協(xié)議 （例如具有前向保密 (FS) 密碼的 TLS、 服務(wù)器的密碼優(yōu)先級(jí) 和安全參數(shù)） 。確保強(qiáng)制執(zhí)行數(shù)據(jù)加密， 如使用HTTP 嚴(yán)格安全傳輸協(xié)議 (HSTS) 等指令。
禁用緩存對(duì)包含敏感數(shù)據(jù)的響應(yīng)。
根據(jù)數(shù)據(jù)分類應(yīng)用實(shí)施所需的安全控制。
不要使用FTP 和SMTP 等傳統(tǒng)協(xié)議來(lái)傳輸敏感數(shù)據(jù)。
使用具有工作因子 （延遲因子） 的強(qiáng)自適應(yīng)和加鹽散列函數(shù)存儲(chǔ)密碼， 例如 Argon2、 scrypt、 bcrypt 或 PBKDF2。
必須選擇適合操作模式的初始化向量。對(duì)于大多數(shù)模式， 可以使用CSPRNG （密碼安全偽隨機(jī)數(shù)生成器） 。對(duì)于需要隨機(jī)數(shù)的模式， 則初始化向量 (IV) 不需要使用CSPRNG。在所有情況下， 對(duì)于一個(gè)固定密鑰， 永 遠(yuǎn)不應(yīng)該使用兩次IV。
始終使用經(jīng)過(guò)驗(yàn)證的加密， 而不僅僅是加密。
密鑰應(yīng)以加密方式隨機(jī)生成并作為字節(jié)數(shù)組存儲(chǔ)在內(nèi)存中。如果使用密碼， 則必須通過(guò)適當(dāng)?shù)拿艽a基密鑰 派生函數(shù)將其轉(zhuǎn)換為密鑰。
確保在適當(dāng)?shù)牡胤绞褂眉用茈S機(jī)性， 并且沒有以可預(yù)測(cè)的方式或低熵進(jìn)行播種。大多數(shù)現(xiàn)代 API 不需要開 發(fā)人員為 CSPRNG 設(shè)置種子以獲得安全性。
避免使用的已廢棄的加密函數(shù)和填充方案， 例如 MD5、 SHA1、 PKCS number 1 v1.5。
單獨(dú)驗(yàn)證每個(gè)安全配置項(xiàng)的有效性。
https://zhuanlan.zhihu.com/p/353034640
0x07 DDOS
防御方法
1、采用高性能的網(wǎng)絡(luò)設(shè)備
首先要保證網(wǎng)絡(luò)設(shè)備不能成為瓶頸，因此選擇路由器、交換機(jī)、硬件防火墻等設(shè)備的時(shí)候要盡量選用知名度高、口碑好的產(chǎn)品。再就是假如和網(wǎng)絡(luò)提供商有特殊關(guān)系或協(xié)議的話就更好了，當(dāng)大量攻擊發(fā)生的時(shí)候請(qǐng)他們?cè)诰W(wǎng)絡(luò)接點(diǎn)處做一下流量限制來(lái)對(duì)抗某些種類的DDoS攻擊是非常有效的。
2、盡量避免NAT的使用
無(wú)論是路由器還是硬件防護(hù)墻設(shè)備要盡量避免采用網(wǎng)絡(luò)地址轉(zhuǎn)換NAT的使用，因?yàn)椴捎么思夹g(shù)會(huì)較大降低網(wǎng)絡(luò)通信能力，其實(shí)原因很簡(jiǎn)單，因?yàn)镹AT需要對(duì)地址來(lái)回轉(zhuǎn)換，轉(zhuǎn)換過(guò)程中需要對(duì)網(wǎng)絡(luò)包的校驗(yàn)和進(jìn)行計(jì)算，因此浪費(fèi)了很多CPU的時(shí)間，但有些時(shí)候必須使用NAT,那就沒有好辦法了。
3、充足的網(wǎng)絡(luò)帶寬保證
網(wǎng)絡(luò)帶寬直接決定了能抗受攻擊的能力，假若僅僅有10M帶寬的話，無(wú)論采取什么措施都很難對(duì)抗現(xiàn)在的SYNFIood攻擊，當(dāng)前至少要選擇100M的共享帶寬，最好的當(dāng)然是掛在1000M的主干上了。但需要注意的是，主機(jī)上的網(wǎng)卡是1000M的并不意味著它的網(wǎng)絡(luò)帶寬就是千兆的，若把它接在100M的交換機(jī)上，它的實(shí)際帶寬不會(huì)超過(guò)100M,再就是接在100M的帶寬上也不等于就有了百兆的帶寬，因?yàn)榫W(wǎng)絡(luò)服務(wù)商很可能會(huì)在交換機(jī)上限制實(shí)際帶寬為10M,這點(diǎn)一定要搞清楚。
4、升級(jí)主機(jī)服務(wù)器硬件
在有網(wǎng)絡(luò)帶寬保證的前提下，請(qǐng)盡量提升硬件配置，要有效對(duì)抗每秒10萬(wàn)個(gè)SYN攻擊包，服務(wù)器的配置至少應(yīng)該為：
P42.4G/DDR512M/SCS1-HD,起關(guān)鍵作用的主要是CPU和內(nèi)存，若有志強(qiáng)雙CPU的話就用它吧，內(nèi)存一定要選擇DDR的高速內(nèi)存，硬盤要盡量選擇SCS的，別只貪DE價(jià)格不貴量還足的便宜，否則會(huì)付出高昂的性能代價(jià)，再就是網(wǎng)卡一定要選用3COM或Intel等名牌的，若是Realtekl的還是用在自己的PC上吧。
5、把網(wǎng)站做成靜態(tài)頁(yè)面或者偽靜態(tài)
大量事實(shí)證明，把網(wǎng)站盡可能做成靜態(tài)頁(yè)面，不僅能大大提高抗攻擊能力，而且還給黑客入侵帶來(lái)不少麻煩，至少到現(xiàn)在為止關(guān)于HTML的溢出還沒出現(xiàn)，看看吧！新浪、搜狐、網(wǎng)易等門戶網(wǎng)站主要都是靜態(tài)頁(yè)面，若你非需要?jiǎng)討B(tài)腳本調(diào)用，那就把它弄到另外一臺(tái)單獨(dú)主機(jī)去，免的遭受攻擊時(shí)連累主服務(wù)器，當(dāng)然，適當(dāng)放一些不做數(shù)據(jù)庫(kù)調(diào)用腳本還是可以的，此外，最好在需要調(diào)用數(shù)據(jù)庫(kù)的腳本中拒絕使用代理的訪問，因?yàn)榻?jīng)驗(yàn)表明使用代理訪問你網(wǎng)站的80%屬于惡意行為。
6、增強(qiáng)操作系統(tǒng)的TCP/IP棧
Win2000和Win2003作為服務(wù)器操作系統(tǒng)，本身就具備一定的抵抗DDoS攻擊的能力，只是默認(rèn)狀態(tài)下沒有開啟而已，
7、安裝專業(yè)抗DDOS防火墻
8、HTTP請(qǐng)求的攔截
如果惡意請(qǐng)求有特征，對(duì)付起來(lái)很簡(jiǎn)單：直接攔截它就行了。
HTTP請(qǐng)求的特征一般有兩種：P地址和User Agent字段。比如，惡意請(qǐng)求都是從某個(gè)IP段發(fā)出的，那么把這個(gè)IP段封掉就行了?；蛘撸鼈兊腢ser Agent字段有特征（包含某個(gè)特定的詞語(yǔ)），那就把帶有這個(gè)詞語(yǔ)的請(qǐng)求攔截。
9、備份網(wǎng)站
你要有一個(gè)備份網(wǎng)站，或者最低限度有一個(gè)臨時(shí)主頁(yè)。生產(chǎn)服務(wù)器萬(wàn)一下線了，可以立刻切換到備份網(wǎng)站，不至于毫無(wú)辦法。
備份網(wǎng)站不一定是全功能的，如果能做到全靜態(tài)瀏覽，就能滿足需求。最低限度應(yīng)該可以顯示公告，告訴用戶，網(wǎng)站出了問題，正在全力搶修。
這種臨時(shí)主頁(yè)建議放到Github Pages或者Netlify,它們的帶寬大，可以應(yīng)對(duì)攻擊，而且都支持綁定域名，還能從源碼自動(dòng)構(gòu)建。
10、部署CDN
CDN指的是網(wǎng)站的靜態(tài)內(nèi)容分發(fā)到多個(gè)服務(wù)器，用戶就近訪問，提高速度。因此，CDN也是帶寬擴(kuò)容的一種方法，可以用來(lái)防御DDOS攻擊。
網(wǎng)站內(nèi)容存放在源服務(wù)器，CDN上面是內(nèi)容的緩存。用戶只允許訪問CDN,如果內(nèi)容不在CDN上，CDN再向源服務(wù)器發(fā)出請(qǐng)求。這樣的話，只要CDN夠大，就可以抵御很大的攻擊。不過(guò)，這種方法有一個(gè)前提，網(wǎng)站的大部分內(nèi)容必須可以靜態(tài)緩存。對(duì)于動(dòng)態(tài)內(nèi)容為主的網(wǎng)站（比如論壇），就要想別的辦法，盡量減少用戶對(duì)動(dòng)態(tài)數(shù)據(jù)的請(qǐng)求；本質(zhì)就是自己搭建一個(gè)微型CDN。各大云服務(wù)商提供的高防P,背后也是這樣做的：網(wǎng)站域名指向高防P,它提供一個(gè)緩沖層，清洗流量，并對(duì)源服務(wù)器的內(nèi)容進(jìn)行緩存。
這里有一個(gè)關(guān)鍵點(diǎn)，一旦上了CDN,千萬(wàn)不要泄露源服務(wù)器的P地址，否則攻擊者可以繞過(guò)CDN直接攻擊源服務(wù)器，前面的努力都白費(fèi)。搜一下'繞過(guò)CDN獲取真實(shí)P地址'，你就會(huì)知道國(guó)內(nèi)的黑產(chǎn)行業(yè)有多猖獗。
11、其他防御措施
以上幾條對(duì)抗DDoS建議，適合絕大多數(shù)擁有自己主機(jī)的用戶，但假如采取以上措施后仍然不能解決DDoS問題，就有些麻煩了，可能需要更多投資，增加服務(wù)器數(shù)量并采用DNS輪巡或負(fù)載均衡技術(shù)，甚至需要購(gòu)買七層交換機(jī)設(shè)備，從而使得抗DDoS攻擊能力成倍提高，只要投資足夠深入。
0x08 安全配置
風(fēng)險(xiǎn)說(shuō)明
您的應(yīng)用程序可能受到攻擊， 如果應(yīng)用程序是：
應(yīng)用程序棧的任何部分缺少適當(dāng)?shù)陌踩庸蹋?或者云服務(wù)的權(quán)限配置錯(cuò)誤。
應(yīng)用程序啟用或安裝了不必要的功能 （例如：不必要的端口、 服務(wù)、 網(wǎng)頁(yè)、 帳戶或權(quán)限） 。
默認(rèn)帳戶和密碼仍然可用且沒有更改。
錯(cuò)誤處理機(jī)制向用戶紕漏堆棧信息或其他大量錯(cuò)誤信息。
對(duì)于升級(jí)的系統(tǒng)， 最新的安全特性被禁用或未安全配置。
應(yīng)用程序服務(wù)器、 應(yīng)用程序框架 （如：Struts、 Spring、 ASP.NET） 、 庫(kù)文件、 數(shù)據(jù)庫(kù)等沒有進(jìn) 行安全配置。
服務(wù)器不發(fā)送安全標(biāo)頭或指令， 或未被設(shè)定安全參數(shù)。
您的應(yīng)用軟件已過(guò)期或易受攻擊 （參見“A6:2021-脆弱和過(guò)時(shí)的組件”） 。
缺少一個(gè)體系的、 可重復(fù)的應(yīng)用程序安全配置過(guò)程， 系統(tǒng)將處于高風(fēng)險(xiǎn)中。
應(yīng)實(shí)施安全的安裝過(guò)程， 包括：
一個(gè)可以快速且易于部署在另一個(gè)鎖定環(huán)境的可重復(fù)的加固過(guò)程。開發(fā)、 質(zhì)量保證和生產(chǎn)環(huán)境都應(yīng) 該進(jìn)行相同配置， 并且在每個(gè)環(huán)境中使用不同的密碼。這個(gè)過(guò)程應(yīng)該是自動(dòng)化的， 以盡量減少安裝 一個(gè)新安全環(huán)境的耗費(fèi)。
搭建最小化平臺(tái)， 該平臺(tái)不包含任何不必要的功能、 組件、 文檔和示例。移除或不安裝不適用的功 能和框架。
檢查和修復(fù)安全配置項(xiàng)來(lái)適應(yīng)最新的安全說(shuō)明、 更新和補(bǔ)丁， 并將其作為更新管理過(guò)程的一部分 （參見 “A6:2021-脆弱和過(guò)時(shí)的組件”） 。在檢查過(guò)程中， 應(yīng)特別注意云存儲(chǔ)權(quán)限 （如：S3桶權(quán) 限） 。
一個(gè)能在組件和用戶間提供有效的分離和安全性的分段應(yīng)用程序架構(gòu)， 包括：分段、 容器化和云安 全組 （ACL） 。
向客戶端發(fā)送安全指令， 例如：安全標(biāo)頭。
一個(gè)能夠驗(yàn)證所有環(huán)境中進(jìn)行了正確的安全配置和設(shè)置的自動(dòng)化過(guò)程。
聯(lián)系客服
