原理: 在開(kāi)發(fā)web應(yīng)用程序時(shí)，開(kāi)發(fā)人員每每只關(guān)注Web應(yīng)用程序所需的功能，因此經(jīng)常會(huì)創(chuàng)建自定義的認(rèn)證和會(huì)話(huà)方案。可是要正確的實(shí)現(xiàn)這些方案倒本章目的

普及OWASP TOP 10包含的內(nèi)容、每種Web應(yīng)用所面臨的安全風(fēng)險(xiǎn)及其所應(yīng)采取的安全策略

OWASP Top 10簡(jiǎn)介

OWASP（Open Web Application Security Project，開(kāi)放式Web應(yīng)用程序安全項(xiàng)目）是一個(gè)在線社區(qū)，開(kāi)源的、非盈利的全球性安全組織，主要在Web應(yīng)用安全領(lǐng)域提供文章、方法論、文檔、工具和技術(shù)，致力于應(yīng)用軟件的安全研究。OWASP的使命是使應(yīng)用軟件更加安全，使企業(yè)和組織能夠?qū)?yīng)用安全風(fēng)險(xiǎn)做出更清晰的決策。目前OWASP全球擁有250個(gè)分部，近7萬(wàn)名會(huì)員，共同推動(dòng)了安全標(biāo)準(zhǔn)、安全測(cè)試工具、安全指導(dǎo)手冊(cè)等應(yīng)用安全技術(shù)的發(fā)展。OWASPTop10列出了公認(rèn)的最有威協(xié)性的Web應(yīng)用安全漏洞，總結(jié)并更新Web應(yīng)用程序中最可能、最常見(jiàn)、最危險(xiǎn)的十大漏洞。

1.sql注入?????????????????????????????

原理： SQL 注入就是指 web 應(yīng)用程序?qū)τ脩?hù)輸入的數(shù)據(jù)合法性沒(méi)有過(guò)濾或者是判斷，前端傳入的參數(shù)是攻擊者能夠控制，而且參數(shù)帶入數(shù)據(jù)庫(kù)的查詢(xún)，將不受信任的數(shù)據(jù)作為命令或查詢(xún)的一部分發(fā)送到解析器時(shí)，會(huì)產(chǎn)生諸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻擊者的惡意數(shù)據(jù)可以誘使解析器在沒(méi)有適當(dāng)授權(quán)的情況下執(zhí)行非預(yù)期命令或訪問(wèn)數(shù)據(jù)，經(jīng)過(guò)構(gòu)造惡意的 sql 語(yǔ)句來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)庫(kù)的任意操作。注入--脆弱點(diǎn) 應(yīng)用程序存在如下情況時(shí)，是脆弱的且易受攻擊：用戶(hù)提供的數(shù)據(jù)沒(méi)有經(jīng)過(guò)應(yīng)用程序的驗(yàn)證、過(guò)濾或凈化 動(dòng)態(tài)查詢(xún)語(yǔ)句或非參數(shù)化的調(diào)用，在沒(méi)有上下文感知轉(zhuǎn)義的情況下，被用于解釋器。在ORM搜索參數(shù)中使用了惡意數(shù)據(jù)，這樣搜索就獲得包含敏感或未授權(quán)的數(shù)據(jù)惡意數(shù)據(jù)直接被使用或連接，諸如SQL語(yǔ)句或命令在動(dòng)態(tài)查詢(xún)語(yǔ)句、命令或存儲(chǔ)過(guò)程中包含結(jié)構(gòu)和惡意數(shù)據(jù) ? 比如： 一、報(bào)錯(cuò)注入 二、基于布爾的盲注 三、延時(shí)注入 四、寬字節(jié)注入 ? 注入--防護(hù)策略 防止注入漏洞需要將數(shù)據(jù)與命令語(yǔ)句、查詢(xún)語(yǔ)句分隔開(kāi)來(lái)。 最佳選擇是使用安全的API，完全避免使用解釋器，或提供參數(shù)化界面的接口，或遷移到ORM或?qū)嶓w框架。 使用正確的或“白名單”的具有恰當(dāng)規(guī)范化的輸入驗(yàn)證方法同樣會(huì)有助于防止注入攻擊，但這不是一個(gè)完整的防御，因?yàn)樵S多應(yīng)用程序在輸入中需要特殊字符，例如文本區(qū)域或移動(dòng)應(yīng)用程序的API。 對(duì)于任何剩余的動(dòng)態(tài)查詢(xún)，可以使用該解釋器的特定轉(zhuǎn)義語(yǔ)法轉(zhuǎn)義特殊字符。OWASP的JavaEncoder和類(lèi)似的庫(kù)提供了這樣的轉(zhuǎn)義例程。 在查詢(xún)中使用LIMIT和其他SQL控件，以防止在SQL注入時(shí)大量地泄露記錄

2.失效的身份認(rèn)證和會(huì)話(huà)管理

原理: 在開(kāi)發(fā)web應(yīng)用程序時(shí)，開(kāi)發(fā)人員每每只關(guān)注Web應(yīng)用程序所需的功能，因此經(jīng)常會(huì)創(chuàng)建自定義的認(rèn)證和會(huì)話(huà)方案。可是要正確的實(shí)現(xiàn)這些方案倒是很難的。結(jié)果就在退出、密碼管理、超時(shí)、密碼找回、賬戶(hù)更新等方面存在漏洞。通過(guò)錯(cuò)誤使用應(yīng)用程序的身份認(rèn)證和會(huì)話(huà)管理功能，攻擊者能夠破譯密碼、密鑰或會(huì)話(huà)令牌，或者利用其它開(kāi)發(fā)缺陷來(lái)暫時(shí)性或永久性冒充其他用戶(hù)的身份。?失效的身份認(rèn)證--脆弱點(diǎn) 應(yīng)用程序存在如下情況時(shí)，那么可能存在身份驗(yàn)證的脆弱性： 允許憑證填充，這使得攻擊者獲得有效用戶(hù)名和密碼的列表 允許暴力破解或其他自動(dòng)攻擊 允許默認(rèn)的、弱的或眾所周知的密碼，例如“Password1”或“admin/admin 使用弱的或失效的驗(yàn)證憑證，忘記密碼程序，例如“基于知識(shí)的答案 使用明文、加密或弱散列密碼（參見(jiàn)：敏感數(shù)據(jù)泄露） 缺少或失效的多因素身份驗(yàn)證 暴露URL中的會(huì)話(huà)ID（例如URL重寫(xiě)） 在成功登錄后不會(huì)更新會(huì)話(huà)ID。 不正確地使會(huì)話(huà)ID失效。當(dāng)用戶(hù)不活躍的時(shí)候，用戶(hù)會(huì)話(huà)或認(rèn)證令牌（特別是單點(diǎn)登錄（SSO）令牌）沒(méi)有正確注銷(xiāo)或失效失效的身份認(rèn)證--防護(hù)策略 在可能的情況下，實(shí)現(xiàn)多因素身份驗(yàn)證，以防止自動(dòng)、憑證填充、暴力破解和被盜憑據(jù)再利用攻擊不要使用發(fā)送或部署默認(rèn)的憑證，特別是管理員用戶(hù)執(zhí)行弱密碼檢查，例如測(cè)試新或變更的密碼，以糾正“排名前10000個(gè)弱密碼將密碼長(zhǎng)度、復(fù)雜性和循環(huán)策略與NIST-800-63B的指導(dǎo)方針（記住秘密）或其他現(xiàn)代的基于證據(jù)的密碼策略相一致確認(rèn)注冊(cè)、憑據(jù)恢復(fù)和API路徑，通過(guò)對(duì)所有輸出結(jié)果使用相同的消息，用以抵御賬戶(hù)枚舉攻擊限制或逐漸延退失敗的登錄嘗試。記錄所有失敗信息并在憑據(jù)填充、暴力破解或其他攻擊被檢測(cè)時(shí)提醒管理員。使用服務(wù)器端安全的內(nèi)置會(huì)話(huà)管理器，在登錄后生成高度復(fù)雜的新隨機(jī)會(huì)話(huà)ID。會(huì)話(huà)ID不能在URL中，可以安全地存儲(chǔ)和當(dāng)?shù)浅觥㈤e置、絕對(duì)超時(shí)后使其失效

3.跨站腳本攻擊 XSS

XSS是跨站腳本攻擊，原理是攻擊者向有XSS漏洞的網(wǎng)站中輸入惡意的HTML代碼。當(dāng)應(yīng)用程序的新網(wǎng)頁(yè)中包含不受信任的、未經(jīng)怡當(dāng)驗(yàn)證或轉(zhuǎn)義的數(shù)據(jù)時(shí)，或者使用可以創(chuàng)建HTML或JavaScript的瀏覽器API更新現(xiàn)有的網(wǎng)頁(yè)時(shí)，就會(huì)出現(xiàn)XSS缺陷。XSS讓攻擊者能夠在受害者的瀏覽器中執(zhí)行腳本，并動(dòng)持用戶(hù)會(huì)話(huà)、破壞網(wǎng)站或?qū)⒂脩?hù)重定向到惡意站點(diǎn)。當(dāng)其它用戶(hù)瀏覽該網(wǎng)站時(shí)，這段HTML代碼會(huì)自動(dòng)執(zhí)行，從而達(dá)到攻擊的目的。跨站腳本（XSS）--脆弱性 典型的XSS攻擊可導(dǎo)致盜取session、賬戶(hù)、繞過(guò)MFA、DIV替換、對(duì)用戶(hù)瀏覽器的攻擊（例如：惡意軟件下載、鍵盤(pán)記錄）以及其他用戶(hù)側(cè)的攻擊。 存在三種XSS類(lèi)型，通常針對(duì)用戶(hù)的瀏覽器：反射式XSS：應(yīng)用程序或API包括未經(jīng)驗(yàn)證和未經(jīng)轉(zhuǎn)義的用戶(hù)輸入，作為HTML輸出的一部分。一個(gè)成功的攻擊可以讓攻擊者在受害者的瀏覽器中執(zhí)行任意的HTML和JavaScript。通常，用戶(hù)將需要與指向攻擊者控制頁(yè)面的某些惡意鏈接進(jìn)行交互，例如惡意漏洞網(wǎng)站，廣告或類(lèi)似內(nèi)容。 存儲(chǔ)式XSS：你的應(yīng)用或者API將未凈化的用戶(hù)輸入存儲(chǔ)下來(lái)了，并在后期在其他用戶(hù)或者管理員的頁(yè)面展示出來(lái)。存儲(chǔ)型XSS一般被認(rèn)為是高危或嚴(yán)重的風(fēng)險(xiǎn)。 基于DOM的XSS：會(huì)動(dòng)態(tài)的將攻擊者可控的內(nèi)容加入頁(yè)面的Javascript框架、單頁(yè)面程序或API存在這種類(lèi)型的漏洞。理想的來(lái)說(shuō)，你應(yīng)該避免將攻擊者可控的數(shù)據(jù)發(fā)送給不安全的JavaScriptAPI。 什么是 HttpOnly? 若是您在 cookie 中設(shè)置了 HttpOnly 屬性，那么經(jīng)過(guò) js 腳本將沒(méi)法讀取到cookie 信息，這樣能有效的防止 XSS 攻擊。 ? 跨站腳本（XSS）--防護(hù)策略 防止XSS需要將不可信數(shù)據(jù)與動(dòng)態(tài)的瀏覽器內(nèi)容區(qū)分開(kāi)。使用設(shè)計(jì)上就會(huì)自動(dòng)編碼來(lái)解決XSS問(wèn)題的框架，如：Ruby3.0或ReactJs。為了避免反射式或存儲(chǔ)式的XSS漏洞，要根據(jù)HTML輸出的上下文（包括：主體、屬性、Javascript、csS或URL）對(duì)所有不可信的HTTP請(qǐng)求數(shù)據(jù)進(jìn)行恰當(dāng)?shù)霓D(zhuǎn)義。在客戶(hù)端修改瀏覽器文檔時(shí)，為了避免DOMXSS攻擊，最好的選擇是實(shí)施上下文敏感數(shù)據(jù)編碼。如果這種情況不能避免，可以采用類(lèi)似上下文敏感的轉(zhuǎn)義技術(shù)應(yīng)用于瀏覽器API。使用內(nèi)容安全策略（CSP）是對(duì)抗XSS的深度防御策略。如果不存在可以通過(guò)本地文件放置惡意代碼的其他漏洞（例如：路徑遍歷覆蓋和允許在網(wǎng)絡(luò)中傳輸?shù)囊资芄舻膸?kù)），則該策略是有效的。

4.直接引用不安全的對(duì)象

定義： 不安全的直接對(duì)象引用（IDOR）容許攻擊者繞過(guò)網(wǎng)站的身份驗(yàn)證機(jī)制，并經(jīng)過(guò)修改指向?qū)ο筮B接中的參數(shù)值來(lái)直接訪問(wèn)目標(biāo)對(duì)象資源，這類(lèi)資源能夠是屬于其余用戶(hù)的數(shù)據(jù)庫(kù)條目以及服務(wù)器系統(tǒng)中的隱私文件等等。 ? 出現(xiàn)的緣由： Web應(yīng)用每每在生成Web頁(yè)面時(shí)會(huì)用它的真實(shí)名字，且并不會(huì)對(duì)全部的目標(biāo)對(duì)象訪問(wèn)時(shí)來(lái)檢查用戶(hù)權(quán)限，因此這就形成了不安全的對(duì)象直接引用的漏洞。 服務(wù)器上的具體文件名、路徑或數(shù)據(jù)庫(kù)關(guān)鍵字等內(nèi)部資源被暴露在URL或網(wǎng)頁(yè)中，攻擊者能夠嘗試直接訪問(wèn)其余資源。 ? 防護(hù)措施： 1.使用基于用戶(hù)或會(huì)話(huà)的間接對(duì)象訪問(wèn)，這樣可防止攻擊者直接攻擊未受權(quán)資源 2.訪問(wèn)檢查：對(duì)任何來(lái)自不受信源所使用的全部對(duì)象進(jìn)行訪問(wèn)控制檢查 3.避免在url或網(wǎng)頁(yè)中直接引用內(nèi)部文件名或數(shù)據(jù)庫(kù)關(guān)鍵字 4.驗(yàn)證用戶(hù)輸入和url請(qǐng)求，拒絕包含./ …/的請(qǐng)求

5.安全配置錯(cuò)誤

定義： 安全配置錯(cuò)誤是最常見(jiàn)的安全問(wèn)題，這通常是由于不安全的默認(rèn)配置、不完整的臨時(shí)配置、開(kāi)源云存儲(chǔ)、錯(cuò)誤的HTTP標(biāo)頭配置以及包含敏感信息的詳細(xì)錯(cuò)誤信息所造成的。因此，我們不僅需要對(duì)所有的操作系統(tǒng)、框架、庫(kù)和應(yīng)用程序進(jìn)行安全配置，而且必須及時(shí)修補(bǔ)和升級(jí)它們。安全配置錯(cuò)誤--脆弱性 應(yīng)用程序存在以下情況，可能受到攻擊：應(yīng)用程序棧堆的任何部分都缺少適當(dāng)?shù)陌踩庸?#xff0c;或者云服務(wù)的權(quán)限配置錯(cuò)誤。 應(yīng)用程序啟用或安裝了不必要的功能（例如：不必要的端口、服務(wù)、網(wǎng)頁(yè)、帳戶(hù)或權(quán)限）。默認(rèn)帳戶(hù)的密碼仍然可用且沒(méi)有更改。 錯(cuò)誤處理機(jī)制向用戶(hù)披露堆棧跟蹤或其他大量錯(cuò)誤信息。 對(duì)于更新的系統(tǒng)，禁用或不安全地配置最新的安全功能。 應(yīng)用程序服務(wù)器、應(yīng)用程序框架（Struts、Spring、ASP.NET）、庫(kù)文件、數(shù)據(jù)庫(kù)等沒(méi)有進(jìn)行安全配置。 服務(wù)器不發(fā)送安全標(biāo)頭或指令，或者未對(duì)服務(wù)器進(jìn)行安全配置。 您的應(yīng)用軟件已過(guò)期或易受攻擊（參見(jiàn)：使用含有已知漏洞的組件）。? 安全配置錯(cuò)誤--防護(hù)策略 一個(gè)可以快速且易于部署在另一個(gè)鎖定環(huán)境的可重復(fù)的加固過(guò)程。 開(kāi)發(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ò)程的一部分，（參見(jiàn)：使用含有已知漏洞的組件）。 在檢查過(guò)程中，應(yīng)特別注意云存儲(chǔ)權(quán)限。 一個(gè)能在組件和用戶(hù)間提供有效的分離和安全性的分段應(yīng)用程序架構(gòu)，包括分段、容器化和云安全組。 向客戶(hù)端發(fā)送安全指令，如：安全標(biāo)頭。 在所有環(huán)境中能夠進(jìn)行正確安全配置和設(shè)置的自動(dòng)化過(guò)程。

6.敏感信息泄露

漏洞描述： 因?yàn)楣芾韱T或者技術(shù)人員等各類(lèi)緣由致使敏感信息泄露。許多web應(yīng)用程序和app都沒(méi)法正確保護(hù)敏感數(shù)據(jù)，攻擊者能夠經(jīng)過(guò)竊取或修改未加密的數(shù)據(jù)來(lái)實(shí)施犯罪行為。未加密的敏感數(shù)據(jù)容易受到破壞，所以，必須要對(duì)敏感數(shù)據(jù)加密，這些數(shù)據(jù)包括：傳輸過(guò)程當(dāng)中的數(shù)據(jù)、存儲(chǔ)的數(shù)據(jù)以及瀏覽器的交互數(shù)據(jù)。 ? 敏感數(shù)據(jù)泄露--脆弱性 對(duì)于敏感數(shù)據(jù)，要確定：在數(shù)據(jù)傳輸過(guò)程中是否使用明文傳輸？這和傳輸協(xié)議相關(guān)，如：HTTP、SMTP和FTP。外部網(wǎng)絡(luò)流量非常危險(xiǎn)。驗(yàn)證所有的內(nèi)部通信，如：負(fù)載平衡器、Web服務(wù)器或后端系統(tǒng)之間的通信。 當(dāng)數(shù)據(jù)被長(zhǎng)期存儲(chǔ)時(shí)，無(wú)論存儲(chǔ)在哪里，它們是否都被加密，包含備份數(shù)據(jù)？ 無(wú)論默認(rèn)條件還是源代碼中，是否還在使用任何舊的或脆弱的加密算法？ 是否使用默認(rèn)加密密鑰，生成或重復(fù)使用脆弱的加密密鑰，或者缺少恰當(dāng)?shù)拿荑€管理或密鑰回轉(zhuǎn)？ 是否強(qiáng)制加密敏感數(shù)據(jù)，例如：用戶(hù)代理（如：瀏覽器）指令和傳輸協(xié)議是否被加密？ 用戶(hù)代理（如：應(yīng)用程序、郵件客戶(hù)端）是否未驗(yàn)證服務(wù)器端證書(shū)的有效性？ 敏感數(shù)據(jù)泄露--防護(hù)策略 對(duì)系統(tǒng)處理、存儲(chǔ)或傳輸?shù)臄?shù)據(jù)分類(lèi)，并根據(jù)分類(lèi)進(jìn)行訪問(wèn)控制。熟悉與敏感數(shù)據(jù)保護(hù)相關(guān)的法律和條例，并根據(jù)每項(xiàng)法規(guī)要求保護(hù)敏感數(shù)據(jù)對(duì)于沒(méi)必要存放的、重要的敏感數(shù)據(jù)，應(yīng)當(dāng)盡快清除，或者通過(guò)PCIDSS標(biāo)記或攔截確保存儲(chǔ)的所有敏感數(shù)據(jù)被加密。確保使用了最新的、強(qiáng)大的標(biāo)準(zhǔn)算法或密碼、參數(shù)、協(xié)議和密匙，并且密鑰管理到位。確保傳輸過(guò)程中的數(shù)據(jù)被加密（HTTPS）；確保數(shù)據(jù)加密被強(qiáng)制執(zhí)行禁止緩存對(duì)包含敏感數(shù)據(jù)的響應(yīng)確保使用密碼專(zhuān)用算法存儲(chǔ)密碼。將工作因素（延退因素）設(shè)置在可接受范圍。單獨(dú)驗(yàn)證每個(gè)安全配置項(xiàng)的有效性。

7.缺乏功能級(jí)的訪問(wèn)控制

原理： 大多數(shù)Web應(yīng)用程序的功能在UI頁(yè)面顯示以前,會(huì)驗(yàn)證功能級(jí)別的訪問(wèn)權(quán)限。不足的日志記錄和監(jiān)控，以及事件響應(yīng)缺失或無(wú)效的集成，使攻擊者能夠進(jìn)一步攻擊系統(tǒng)、保持持續(xù)性或轉(zhuǎn)向更多系統(tǒng)，以及算改、提取或銷(xiāo)毀數(shù)據(jù)，比如若是請(qǐng)求沒(méi)有被驗(yàn)證,攻擊者可以偽造請(qǐng)求從而在未經(jīng)適當(dāng)受權(quán)時(shí)訪問(wèn)功能。 ? 測(cè)試方法： 一、 保證合法受權(quán)用戶(hù)能夠訪問(wèn)成功 二、 限制非法未受權(quán)用戶(hù)的訪問(wèn) ? 防護(hù)措施： 一、 設(shè)計(jì)嚴(yán)格的權(quán)限控制系統(tǒng)，對(duì)于每一個(gè)請(qǐng)求和URL都要進(jìn)行校驗(yàn)和權(quán)限確認(rèn)，防止非法請(qǐng)求被執(zhí)行 二、 對(duì)于每一個(gè)功能的訪問(wèn)，都要有明確的角色受權(quán)，采用過(guò)濾器的方式校驗(yàn)每一個(gè)請(qǐng)求的合法性 三、 實(shí)現(xiàn)Web訪問(wèn)的IP白名單列表，禁止不可信的IP訪問(wèn)Web系統(tǒng)

8.跨站請(qǐng)求偽造 CSRF

CSRF概念： CSRF跨站點(diǎn)請(qǐng)求偽造(Cross—Site Request Forgery)，跟XSS攻擊同樣，存在巨大的危害性，你能夠這樣來(lái)理解：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求，對(duì)服務(wù)器來(lái)講這個(gè)請(qǐng)求是徹底合法的，可是卻完成了攻擊者所指望的一個(gè)操做，攻擊者可以利用外部實(shí)體竊取使用URI文件處理器的內(nèi)部文件和共享文件、監(jiān)聽(tīng)內(nèi)部掃描端口、執(zhí)行遠(yuǎn)程代碼和實(shí)施拒絕服務(wù)攻擊。以下：其中Web A為存在CSRF漏洞的網(wǎng)站，Web B為攻擊者構(gòu)建的惡意網(wǎng)站，User C為Web A網(wǎng)站的合法用戶(hù)。 ? CSRF攻擊攻擊原理及過(guò)程以下： 1. 用戶(hù)C打開(kāi)瀏覽器，訪問(wèn)受信任網(wǎng)站A，輸入用戶(hù)名和密碼請(qǐng)求登陸網(wǎng)站A； 2.在用戶(hù)信息經(jīng)過(guò)驗(yàn)證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶(hù)登陸網(wǎng)站A成功，能夠正常發(fā)送請(qǐng)求到網(wǎng)站A； 3. 用戶(hù)未退出網(wǎng)站A以前，在同一瀏覽器中，打開(kāi)一個(gè)TAB頁(yè)訪問(wèn)網(wǎng)站B； 4. 網(wǎng)站B接收到用戶(hù)請(qǐng)求后，返回一些攻擊性代碼，并發(fā)出一個(gè)請(qǐng)求要求訪問(wèn)第三方站點(diǎn)A； 5. 瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請(qǐng)求，在用戶(hù)不知情的狀況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請(qǐng)求。網(wǎng)站A并不知道該請(qǐng)求實(shí)際上是由B發(fā)起的，因此會(huì)根據(jù)用戶(hù)C的Cookie信息以C的權(quán)限處理該請(qǐng)求，致使來(lái)自網(wǎng)站B的惡意代碼被執(zhí)行。 ? 分類(lèi)： GET型和POST型。 ? 防護(hù)手段： 一、驗(yàn)證 HTTP Referer 字段。根據(jù)HTTP協(xié)議，在HTTP頭中有一個(gè)字段叫Referer，它記錄了該HTTP請(qǐng)求的來(lái)源地址。 二、在請(qǐng)求地址中添加 token 并驗(yàn)證在HTTP請(qǐng)求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的token（隨機(jī)字符串），并在服務(wù)器端創(chuàng)建一個(gè)攔截器來(lái)驗(yàn)證這個(gè)token，若是請(qǐng)求中沒(méi)有token或者token內(nèi)容不正確，則認(rèn)為多是CSRF攻擊而拒絕該請(qǐng)求。 三、二次驗(yàn)證在轉(zhuǎn)帳等關(guān)鍵操做以前提供當(dāng)前用戶(hù)的密碼或者驗(yàn)證碼。二次驗(yàn)證能夠有效防護(hù)CSRF 攻擊。

9.使用含有已知漏洞的組件

原理： 使用含有已知漏洞的組件（例如：庫(kù)、框架和其他軟件模塊）擁有和應(yīng)用程序相同的權(quán)限。如果應(yīng)用程序中含有已知漏洞的組件被攻擊者利用，可能會(huì)造成嚴(yán)重的數(shù)據(jù)丟失或服務(wù)器接管。同時(shí)，使用含有已知漏洞的組件的應(yīng)用程序和API可能會(huì)破壞應(yīng)用程序防御、造成各種攻擊并產(chǎn)生嚴(yán)重影響。 含有已知漏洞的組件--脆弱性 如果滿(mǎn)足下面的某個(gè)條件，那么應(yīng)用程序就易受此類(lèi)攻擊： 如果不知道所有使用的組件版本信息（包括：服務(wù)端和客戶(hù)端）。這包括了直接使用的組件或其依賴(lài)的組件。如果軟件易受攻擊，不再支持或者過(guò)時(shí)。這包括：OS、Web服務(wù)器、應(yīng)用程序服務(wù)器、數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）、應(yīng)用程序、API和所有的組件、運(yùn)行環(huán)境和庫(kù)。 如果你定期做漏洞掃描和訂閱你使用組件的安全公告。 如果不基于風(fēng)險(xiǎn)并及時(shí)修復(fù)或升級(jí)底層平臺(tái)、框架和依賴(lài)庫(kù)。很可能發(fā)生這種情況：根據(jù)變更控制，每月或每季度進(jìn)行升級(jí)，這使得組織在這段時(shí)間內(nèi)會(huì)受到已修復(fù)但未修補(bǔ)的漏洞的威脅。 如果軟件工程師沒(méi)有對(duì)更新的、升級(jí)的或打過(guò)補(bǔ)丁的組件進(jìn)行兼容性測(cè)試 如果你沒(méi)有對(duì)組件進(jìn)行安全配置。 使用含有已知漏洞的組件-防護(hù)策略應(yīng)該制定一個(gè)補(bǔ)丁管理流程： 移除不使用的依賴(lài)、不需要的功能、組件、文件和文檔。利用如versions、DependencyCheck、retirejs等工具來(lái)持續(xù)的記錄客戶(hù)端和服務(wù)器端以及它們的依賴(lài)庫(kù)的版本信息。 持續(xù)監(jiān)控如CVE和NVD等是否發(fā)布已使用組件的漏洞信息。 訂閱關(guān)于使用組件安全漏洞的警告郵件。 僅從官方渠道安全的獲取組件，使用簽名機(jī)制降低組件被算改或惡意漏洞的風(fēng)險(xiǎn)。 監(jiān)控那些不再維護(hù)或者不發(fā)布安全補(bǔ)丁的庫(kù)和組件。 如果不能打補(bǔ)丁，可以考慮部署虛擬補(bǔ)丁來(lái)監(jiān)控、檢測(cè)或保護(hù)。 每個(gè)組織都應(yīng)該制定相應(yīng)的計(jì)劃，對(duì)整個(gè)軟件生命周期進(jìn)行監(jiān)控、評(píng)審、升級(jí)或更改配置。

10.未驗(yàn)證的重定向和轉(zhuǎn)發(fā)

重定向： 重定向是服務(wù)端根據(jù)邏輯，發(fā)送一個(gè)狀態(tài)碼（一般為3xx），告訴瀏覽器從新去請(qǐng)求那個(gè)地址.因此地址欄顯示的是新的URL。（重定向是在客戶(hù)端完成的） 轉(zhuǎn)發(fā)： 轉(zhuǎn)發(fā)是在服務(wù)器內(nèi)部將請(qǐng)求轉(zhuǎn)發(fā)給另外一個(gè)資源，把那個(gè)URL的響應(yīng)內(nèi)容讀取過(guò)來(lái),而后把這些內(nèi)容再發(fā)給瀏覽器.瀏覽器根本不知道服務(wù)器發(fā)送的內(nèi)容從哪里來(lái)的,由于這個(gè)跳轉(zhuǎn)過(guò)程是在服務(wù)器實(shí)現(xiàn)的，并非在客戶(hù)端實(shí)現(xiàn)的因此客戶(hù)端并不知道這個(gè)跳轉(zhuǎn)動(dòng)做，因此它的地址欄仍是原來(lái)的地址。（轉(zhuǎn)發(fā)是在服務(wù)器端完成的） ? 二者的區(qū)別： 一、重定向是瀏覽器向服務(wù)器發(fā)送一個(gè)請(qǐng)求并收到響應(yīng)后再次向一個(gè)新地址發(fā)出請(qǐng)求，轉(zhuǎn)發(fā)是服務(wù)器收到請(qǐng)求后為了完成響應(yīng)跳轉(zhuǎn)到一個(gè)新的地址。 二、重定向有兩次請(qǐng)求，不共享數(shù)據(jù)，轉(zhuǎn)發(fā)是有一次請(qǐng)求且共享數(shù)據(jù)。 三、重定向后地址欄會(huì)發(fā)生變化，轉(zhuǎn)發(fā)不會(huì)。 四、重定向的地址能夠是任意地址，轉(zhuǎn)發(fā)的地址只能是當(dāng)前應(yīng)用類(lèi)的某一個(gè)地址。 ? 預(yù)防措施： 一、重定向外部網(wǎng)站須要驗(yàn)證是否在白名單。 二、轉(zhuǎn)發(fā)內(nèi)部網(wǎng)站要驗(yàn)證是否有權(quán)限,有權(quán)限才轉(zhuǎn)發(fā)。

總結(jié)

以上是生活随笔為你收集整理的OWASPTop10安全风险与防护的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。