owasp-Top10（更新ing）

一，什么是owasp和owasp top 10

OWASP：全称Open Web Application Security Project（开放式Web应用程序安全项目）

OWASP TOP 10：OWASP公司公布的10种最严重、最常见的web应用漏洞

官网链接：https://owasp.org/Top10/

 

 

 

二，2021年Top10（官网目前只给到2021年的）

 

 A01：失效的访问控制

常见的CWE包括：将敏感信息泄露给未经授权的参与者、通过发送的数据泄露敏感信息、跨站请求伪造（csrf）

风险说明

​ 访问强制实施策略，使用户无法在其预期权限之外操作。失败的访问控制通常导致未经授权的信息泄露，修改或者销毁所有数据，或在用户权限之外执行业务功能。

常见的访问控制弱点

• 违反最小权限原则或默认拒绝原则，即访问权限应只授予特定能力、角色或用户，但实际上任何人都可以访问

• 通过修改URL（参数修改或强制浏览），内部应用程序状态或者HTML页面，或者使用修改API请求的攻击工具绕过访问控制检查

• 通过提供唯一的标识符允许查看或编辑他人账户

• API没有对POST、PUT和DELETE强制执行访问控制

• 特权提升，在未登陆的情况下假扮用户或以用户身份登入时充当管理员

示例攻击场景

•  应用程序在访问帐户信息的 SQL 调用中使用未经验证的数据：

pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );

• 攻击者只需修改浏览器的“acct”参数即可发送他们想要的任何帐号。如果未正确验证，攻击者可以访问任何用户的帐户。

https://example.com/app/accountInfo?acct=notmyacct

• 攻击者只是强制浏览目标 URL。访问管理页面需要管理员权限。

https://example.com/app/getappInfo https://example.com/app/admin_getappInfo

预防措施

开发人员和QA人员应进行访问控制功能的单元测试和集成测试

访问控制只在受信服务器端代码或者无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据

• 除公有资源外，默认访问拒绝

• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨资源共享（CORS）的使用

• 建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、读取、更新或删除的任何记录

• 在日志中记录失败的访问控制，并在适当时向管理员告警（例如：重复故障）

 

 A02：加密机制失效

以前称为“敏感数据泄露”。敏感数据泄露更像是一种常见的表象问题而不是根本原因，这项风险重点是与加密机制相关的故障（或缺乏加密机制）

风险说明

​ 首先要确认：对传输中的数据和存储数据都有哪些保护需求。例如：密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护。

对于数据，要确认：

• 在传输数据过程中是否使用明文传输？这和传输协议有关：HTTP、SMTP、经过TLS升级的FTP。外部网络流量是有害的，需要验证所有的内部通信

• 无论是在默认情况还是在旧的代码中，是否还在使用任何旧或者脆弱的加密算法或传输协议

• 是否默认使用加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理或密钥回转

• 接收到的服务器证书和信任链是否经过正确验证

示例攻击场景

场景#1：应用程序使用自动数据库加密对数据库中的信用卡号进行加密。但是，此数据在检索时会自动解密，从而允许 SQL 注入漏洞以明文形式检索信用卡号。

场景 #2：网站不对所有页面使用或强制实施 TLS 或支持弱加密。攻击者监视网络流量（例如，在不安全的无线网络上），将连接从 HTTPS 降级为 HTTP，拦截请求，并窃取用户的会话 cookie。攻击者然后重放此 cookie 并劫持用户的（经过身份验证的）会话，访问或修改用户的私人数据。代替上述，他们可以改变所有传输的数据，例如，汇款的接收者。

场景#3：密码数据库使用无盐或简单的散列来存储每个人的密码。文件上传漏洞允许攻击者检索密码数据库。所有未加盐的散列都可以通过预先计算的散列的彩虹表公开。由简单或快速散列函数生成的散列可能会被 GPU 破解，即使它们被加盐。

预防措施

• 对应用程序处理、存储或者传输的数据分类，并根据相关要求确认哪些数据敏感

• 对于没有必要存储的敏感数据，应当尽快清除

• 确保加密存储所有的敏感数据

• 确保使用了最新的，强大的标准算法、协议和密钥，并且密钥管理到位

• 禁用缓存对包含敏感数据的响应

• 不要使用传统协议HTTP、FTP等来传输敏感数据

 

A03：注入

敏感数据泄露更像是一种常见的表象问题而不是根本原因，这项风险重点是与加密机制相关的故障（或缺乏加密机制）

风险说明

源代码审查是检查应用程序是否易受注入攻击的最佳方法。

强烈鼓励针对所有参数、标题、URL、cookie、JSON、SOAP和XML数据输入的自动测试

风险产生情况：

应用程序不会验证、过滤或清洗用户提供的数据
动态查询或无上下文感知转义的非参数化调用之间在解释器中使用
恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据

示例攻击场景

场景 #1：应用程序在构造以下易受攻击的 SQL 调用时使用了不受信任的数据：

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

场景 #2：类似地，应用程序对框架的盲目信任可能会导致查询仍然易受攻击（例如，Hibernate 查询语言 (HQL)）：

 Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

在这两种情况下，攻击者都会修改浏览器中的“id”参数值以发送：'或'1'='1。例如：

 http://example.com/app/accountView?id=' or '1'='1

预防措施

防止注入需要将数据与命令和查询分开：

• 推荐的选择是使用安全的API
• 使用肯定或者白名单服务器端输入验证
• 对于任何残余的动态查询，使用该解释器的特定转义语法转义特殊字符
• 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量披露记录

 

 A04：不安全设计

这是2021的一个新类别，侧重于设计和体系结构缺陷相关的风险，呼吁更多的使用威胁建模、安全设计模式和参考体系结构

风险说明

不安全设计和不安全实现直接存在差异，我们区别设计缺陷和实现缺陷是有原因的，安全设计仍然可能存在实现缺陷，从而导致可能被利用的漏洞。

一个不安全设计不能通过一个完美的实现来修复。

需求和资源管理

收集并与业务协商应用程序的业务需求，包括有关所有数据资产的机密性、完整性、可用性和真实性以及预期业务逻辑的保护要求。考虑您的应用程序的暴露程度以及是否需要隔离租户（除了访问控制）。编制技术要求，包括功能和非功能安全要求。规划和协商涵盖所有设计、构建、测试和运营的预算，包括安全活动。

安全设计

安全设计是一种不断评估威胁并确保代码经过稳健设计和测试以防止已知攻击方法的文化和方法。威胁建模应整合到改进会议（或类似活动）中；寻找数据流和访问控制或其他安全控制的变化。在用户故事开发中确定正确的流程和故障状态，确保它们被负责和受影响的各方充分理解和同意。分析预期和失败流的假设和条件，确保它们仍然准确和可取。确定如何验证假设并强制执行适当行为所需的条件。确保结果记录在用户故事中。从错误中吸取教训并提供积极的激励措施来促进改进。

安全开发生命周期

安全软件需要安全的开发生命周期、某种形式的安全设计模式、铺平道路方法、安全组件库、工具和威胁建模。在整个项目和软件维护过程中，在软件项目开始时联系您的安全专家。考虑利用OWASP 软件保障成熟度模型 (SAMM)来帮助构建您的安全软件开发工作。

示例攻击场景

场景 #1：凭证恢复工作流程可能包括“问答”，这是 NIST 800-63b、OWASP ASVS 和 OWASP Top 10 所禁止的。不能将问答作为多个人身份的证据。可以知道答案，这就是他们被禁止的原因。应该删除此类代码并用更安全的设计替换。

情景#2：一家电影院线允许团体预订折扣，并且在需要押金之前最多有十五名参加者。攻击者可以对这一流程进行威胁建模，并测试他们是否可以在几个请求中一次预订 600 个座位和所有电影院，从而造成巨大的收入损失。

场景#3：一家零售连锁店的电子商务网站没有针对购买高端显卡转售拍卖网站的黄牛运行的僵尸程序的保护。这为视频卡制造商和零售连锁店所有者造成了可怕的宣传，并与无法以任何价格获得这些卡的爱好者产生了持久的不良关系。仔细的反机器人设计和领域逻辑规则，例如在几秒钟内购买，可能会识别出不真实的购买并拒绝此类交易。

预防措施

• 与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制

• 限制用户或服务的资源消耗

• 通过设计咋所有层中严格隔离租户

• 根据暴露和保护需要，对系统层和网络层进行分层

 

 A05：安全配置错误

从上一版的第六名提升，90%都进行了某种形式的配置错误测试。

风险说明

​ 缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中

你的应用程序可能受到攻击，如果应用程序是：

• 应用程序栈的任何部分缺少适当的安全加固，或者云服务的权限配置错误

• 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、账户或权限）

• 默认账户和密码仍然可用且没有更改

• 错误处理机制向用户纰漏堆栈信息或其他大量错误信息

• 对于升级的系统，最新的安全特性被禁用或未安全配置

• 应用程序服务器、应用程序框架（如：Struts、Spring、ASP。net）、库文件、数据库等没有进行安全配置

示例攻击场景

场景 #1：应用程序服务器附带未从生产服务器中删除的示例应用程序。这些示例应用程序具有已知的安全漏洞，攻击者可以利用这些漏洞破坏服务器。假设这些应用程序之一是管理控制台，并且默认帐户没有更改。在这种情况下，攻击者使用默认密码登录并接管。

场景 #2：服务器上未禁用目录列表。攻击者发现他们可以简单地列出目录。攻击者找到并下载已编译的 Java 类，他们对其进行反编译和逆向工程以查看代码。然后，攻击者会在应用程序中发现一个严重的访问控制漏洞。

场景#3：应用服务器的配置允许向用户返回详细的错误消息，例如堆栈跟踪。这可能会暴露敏感信息或潜在缺陷，例如已知易受攻击的组件版本。

场景 #4：云服务提供商 (CSP) 具有由其他 CSP 用户向 Internet 开放的默认共享权限。这允许访问存储在云存储中的敏感数据。

预防措施

应实施安全的安装过程，包括

• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的消耗

• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和实例。移除或不安装不适用的功能和框架

• 检查和修复安全配置来适应最新的安全说明、更新和补丁，并将作为更新管理过程的一部分

• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构

 

 A06：自带缺陷和过时的组件

风险说明

​ 如满足下面的某个条件，那么你的应用就易受到此类攻击：

• 你不知道所使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
• 软件易受攻击，不再支持或过时。
• 没有定期做漏洞扫描和订阅使用组件的安全公告
• 软件工程师没有对更新的、升级的或者打过补丁的组件进行兼容性测试
• 没有对组件进行安全配置

示例攻击场景

场景 #1：组件通常以与应用程序本身相同的权限运行，因此任何组件中的缺陷都可能导致严重影响。这种缺陷可能是偶然的（例如，编码错误）或故意的（例如，组件中的后门）。发现的一些可利用组件漏洞示例如下：

• CVE-2017-5638 是一个 Struts 2 远程代码执行漏洞，可以在服务器上执行任意代码，已被归咎于重大漏洞。

• 虽然物联网 (IoT) 通常很难或不可能修补，但修补它们的重要性可能很大（例如，生物医学设备）。

有一些自动化工具可以帮助攻击者找到未打补丁或配置错误的系统。例如，Shodan IoT 搜索引擎可以帮助您找到仍然遭受 2014 年 4 月修补的 Heartbleed 漏洞的设备。

预防措施

每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置制定一个补丁管理流程：

• 移除不使用的依赖、不需要的功能、组件、文件和文档
• 仅从官方渠道安全的获取组件，并使用前面机制来降低组件被篡改或加入恶意漏洞的风险
• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，就考虑部署虚拟补丁来监控、检查或保护

 

 A07：身份识别和身份验证错误

之前称为无效的身份认证，此类别从第二名下滑，现在包含了与身份识别失效相关的CWE

风险说明

• 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击

• 允许暴力或其他自动化攻击

• 允许预设、脆弱、常见的密码

• 使用脆弱或无效的认证资讯回复或忘记密码的流程

• 使用明码，被加密的或使用较脆弱杂凑法的密码

示例攻击场景

场景#1：凭证填充，使用已知密码列表，是一种常见的攻击。假设应用程序没有实现自动威胁或撞库保护。在这种情况下，应用程序可以用作密码预言机来确定凭据是否有效。

场景#2：大多数身份验证攻击是由于继续使用密码作为唯一因素而发生的。一旦被认为是最佳实践，密码轮换和复杂性要求会鼓励用户使用和重用弱密码。建议组织根据 NIST 800-63 停止这些做法并使用多因素身份验证。

场景 #3：应用程序会话超时设置不正确。用户使用公共计算机访问应用程序。用户没有选择“注销”，而是简单地关闭浏览器选项卡并走开。一个小时后，攻击者使用相同的浏览器，用户仍然通过身份验证。

预防措施

• 实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单
• 在可能的情况下，实施多因素认证来防止自动化撞库攻击，暴力破解，以及遭窃认证咨询被重复利用的攻击
• 不要交付或部署任何预设的认证凭证，特别是管理者
• 限制或增加登入失败尝试的延迟

 

 A08：软件和数据完整性故障

2021 年的一个新类别侧重于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。常见漏洞和暴露/常见漏洞评分系统 (CVE/CVSS) 数据中权重最高的影响之一。值得注意的常见弱点枚举 (CWE) 包括 CWE-829：包含不受信任的控制领域的功能、 CWE-494：下载没有完整性检查的代码和 CWE-502：不受信任的数据的反序列化。

软件和数据完整性故障与不能防止完整性违规的代码和基础设施有关。这方面的一个示例是应用程序依赖来自不受信任的来源、存储库和内容交付网络 (CDN) 的插件、库或模块。不安全的 CI/CD 管道可能会带来未经授权的访问、恶意代码或系统破坏的可能性。最后，现在许多应用程序都包含自动更新功能，在没有足够完整性验证的情况下下载更新并应用于以前受信任的应用程序。攻击者可能会上传他们自己的更新以分发并在所有安装上运行。另一个例子是对象或数据被编码或序列化为攻击者可以看到和修改的结构容易受到不安全的反序列化的影响。

示例攻击场景

场景 #1 更新而不签名：许多家用路由器、机顶盒、设备固件等不通过签名固件验证更新。未签名的固件是攻击者日益增长的目标，预计只会变得更糟。这是一个主要问题，因为很多时候除了在将来的版本中修复并等待以前的版本老化之外，没有任何补救机制。

场景 #2 SolarWinds 恶意更新：已知民族国家会攻击更新机制，最近的一次值得注意的攻击是 SolarWinds Orion 攻击。开发该软件的公司拥有安全的构建和更新完整性流程。尽管如此，这些都能够被破坏，并且几个月来，该公司向 18,000 多个组织分发了一个高度针对性的恶意更新，其中大约 100 个左右受到影响。这是历史上对这种性质的最深远和最重大的破坏之一。

场景 #3 不安全的反序列化： React 应用程序调用一组 Spring Boot 微服务。作为函数式程序员，他们试图确保他们的代码是不可变的。他们提出的解决方案是序列化用户状态并在每个请求中来回传递。攻击者注意到“rO0”Java 对象签名（在 base64 中）并使用 Java Serial Killer 工具在应用程序服务器上获得远程代码执行。

预防措施

• 使用数字签名或类似机制来验证软件或数据是否来自预期来源并且未被更改。

• 确保库和依赖项，例如 npm 或 Maven，正在使用受信任的存储库。如果您的风险较高，请考虑托管经过审查的内部已知良好的存储库。

• 确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞

• 确保对代码和配置更改进行审查，以最大程度地减少将恶意代码或配置引入您的软件管道的可能性。

• 确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性。

• 确保未签名或未加密的序列化数据在没有某种形式的完整性检查或数字签名的情况下不会发送到不受信任的客户端，以检测序列化数据的篡改或重放

 

 A09：安全日志和监控故障

风险说明

如果不进行日志记录和检测，就无法发现任何违规行为，任何时候都会发现日志记录、检测、监视和主动响应不足的情况：

• 日志只存储在本地

• 渗透测试和动态应用安全测试工具的扫描没有触发情报

• 警告和错误生成的日志或日志记录不充分或日志消息不清晰

示例攻击场景

场景 #1：由于缺乏监控和记录，儿童健康计划提供商的网站运营商无法检测到违规行为。外部方告知健康计划提供者，攻击者访问并修改了超过 350 万儿童的数千条敏感健康记录。事后审查发现，网站开发人员没有解决重大漏洞。由于系统没有记录或监控，数据泄露可能自 2013 年以来一直在进行，持续时间超过 7 年。

情景#2：一家主要的印度航空公司发生数据泄露事件，涉及数百万乘客十多年的个人数据，包括护照和信用卡数据。数据泄露发生在第三方云托管服务提供商处，该服务提供商在一段时间后通知了航空公司。

场景 #3：一家主要的欧洲航空公司遭受了 GDPR 可报告的违规行为。据报道，该漏洞是由攻击者利用支付应用程序安全漏洞引起的，攻击者获取了超过 400,000 条客户支付记录。该航空公司因此被隐私监管机构罚款 2000 万英镑。

预防措施

开发人员应根据应用程序的风险实施部分或全部以下控制：

• 确保可以使用足够的用户上下文记录所有登录、访问控制和服务器端输入验证失败，以识别可疑或恶意帐户，并保留足够的时间以允许延迟取证分析。

• 确保以日志管理解决方案可以轻松使用的格式生成日志。

• 确保对日志数据进行正确编码，以防止对日志或监控系统的注入或攻击。

• 确保高价值交易具有带有完整性控制的审计跟踪，以防止篡改或删除，例如仅附加的数据库表或类似的。

• DevSecOps 团队应建立有效的监控和警报，以便快速检测和响应可疑活动。

• 建立或采用事件响应和恢复计划，例如美国国家标准与技术研究院 (NIST) 800-61r2 或更高版本。

有商业和开源应用程序保护框架，例如 OWASP ModSecurity Core Rule Set，以及具有自定义仪表板和警报功能的开源日志关联软件，例如 Elasticsearch、Logstash、Kibana (ELK) 堆栈。

 

 A010：服务端请求伪造

风险说明

​ 一旦web应用程序在获取远程资源时没有验证用户提供的URL，就会出现ssrf缺陷。它允许攻击者强制应用程序发送一个精心构造的请求到意外的目的地，即使是在有防火墙，VPN获其他类型的网络访问控制列表保护的情况下

示例攻击场景

攻击者可以使用 SSRF 攻击受 Web 应用程序防火墙、防火墙或网络 ACL 保护的系统，使用的场景如下：

场景 #1：端口扫描内部服务器——如果网络架构未分段，攻击者可以绘制内部网络，并根据连接结果或连接或拒绝 SSRF 有效负载连接所用的时间来确定内部服务器上的端口是打开还是关闭。

场景#2：敏感数据暴露——攻击者可以访问本地文件或内部服务来获取敏感信息，例如file:///etc/passwd</span>和http://localhost:28017/.

场景 #3：访问云服务的元数据存储 - 大多数云提供商都有元数据存储，例如http://169.254.169.254/. 攻击者可以读取元数据以获取敏感信息。

场景 #4：破坏内部服务——攻击者可以滥用内部服务进行进一步的攻击，例如远程代码执行 (RCE) 或拒绝服务 (DoS)。

预防措施

开发人员可以通过实施以下部分或全部深度防御控制来防止 SSRF：

从网络层

• 在单独的网络中分段远程资源访问功能以减少 SSRF 的影响

• 强制执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除基本 Intranet 流量之外的所有流量。
  提示：
  ~ 为基于应用程序的防火墙规则建立所有权和生命周期。
  ~ 在防火墙上记录所有接受和阻止的网络流（请参阅A09:2021-安全记录和监控失败）。

从应用层：

• 清理和验证所有客户端提供的输入数据

• 使用肯定的允许列表强制 URL 架构、端口和目标

• 不要向客户发送原始响应

• 禁用 HTTP 重定向

• 请注意 URL 一致性以避免诸如 DNS 重新绑定和“检查时间、使用时间”(TOCTOU) 竞争条件等攻击

不要通过使用拒绝列表或正则表达式来缓解 SSRF。攻击者拥有绕过拒绝列表的有效负载列表、工具和技能。

需要考虑的其他措施：                 

•   不要在前端系统（例如 OpenID）上部署其他安全相关服务。控制这些系统上的本地流量（例如 localhost）
•    对于具有专用和可管理用户组的前端，在独立系统上使用网络加密（例如 VPN）来考虑非常高的保护需求

 

三，写后感