开放式Web应用程序安全项目(OWASP) Top 10 2021整理。
与2017的不同
- XXE外部实体(XML External Entities)归入安全配置错误。
- XSS跨站脚本归入注入。
- 不安全的反序列化归入软件和数据完整性故障。
- 新增服务端伪造请求SSRF。
- 新增不安全设计。
Top 10
- 失效的访问控制
- 加密机制失效
- 注入
- 不安全设计
- 安全配置错误
- 自带缺陷和过时的组件
- 身份识别和身份验证错误
- 软件和数据完整性故障
- 安全日志和监控故障
- 服务端请求伪造
1. 失效的访问控制 Broken Access Control
- 常见的CWE:
- 将敏感信息泄露给未经授权的参与者
-
通过发送到数据泄露敏感信息
-
跨站请求伪造CSRF
-
风险说明
访问控制强制实施策略,使用户无法在预期权限之外进行操作。失败的控制访问通常会导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱包括:
- 违反最小特权原则或默认拒绝原则,即访问权限应该只授予特定能力、角色或用户,但实际上任何人都可以访问。
- 通过修改URL(参数篡改或强制浏览)、内部应用程序状态或HTML页面,或使用修改API请求的攻击工具来绕过访问控制检查。
- 通过提供唯一标识符(不安全的直接对象引用)允许查看或编辑其他人的账户。
- API没有对POST、PUT、DELETE强制执行访问控制。
- 特权提升。在未登录的情况下假扮用户或以用户身份登录时充当管理员。
- 元数据操作,假如通过重放或篡改JSON Web令牌(JWT)来访问控制令牌,或操纵Cookie或隐藏字段以提升权限,或滥用JWT失效。
- CORS配置错误以致允许未授权或不可信的API访问。
- 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面或作为标准用户身份访问特权页面。
- 预防措施
访问控制只在受信服务器端代码或无服务器API中有效,这样攻击者才无法修改访问控制检查或元数据。
- 除共有资源外,默认为“拒绝访问”。
- 使用一次性的访问控制机制,并在整个应用程序中不断重用它们,包括最小化跨资源共享(CORS)的使用。
- 建立访问控制模型以强制执行所有权记录,而不是简单接受用户创建、读取、更新或删除的任何记录。
- 特别的业务应用访问限制需求应由领域模型强制执行。
- 禁用Web服务器目录列表,并确保文件元数据(例如:.git)和备份文件不存在与Web的根目录中。
- 在日志中记录失败的访问控制,并适当时想管理员警告(例如:重复故障)。
- 对API的控制器的访问进行速率限制,以最大限度地降低自动化攻击工具带来的危害。
- 当用户注销后,服务器上的状态会话标识符应失效。无状态的JWT令牌应该是短暂的,以便让攻击者的攻击机会窗口最小化。对于时间较长的JWT,强烈建议遵循OAuth标准来撤销访问。
- 开发人员和QA人员应进行访问控制功能的单元测试和集成测试。
- 范例
- https://example.com/app/accountInfo?acct=not myacct
pstmt.setString(1, request.getParameter(“acct”)); ResultSet results = pstmt.executeQuery( );
- https://example.com/app/admin_getappInfo
https://example.com/app/getappInfo
2. 加密机制失效 Cryptographic Failures
以前称为“敏感数据泄露”。“敏感数据泄露”只是表面原因而不是根本原因,这项风险的重点是与加密机制相关的故障(或缺乏加密机制)。这往往会导致敏感数据泄露。
- 常见CWE:
- 使用硬编码密码
- 损坏或有风险的加密算法
- 熵不足
- 风险说明
首先要确认:对传输中数据和村粗都有哪些保护需求。 例如,密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护,尤其是在这些数据属于隐私保护法(如:欧盟GDPR) 或法规条例(如:金融数据保护标准PCI DSS)适用范围的情况下。 对于这些数据,要确定:
- 在传输过程中使用明文传输
- 使用旧或脆弱的加密算法或传输协议
- 使用默认加密密钥、生成或重复使用脆弱的加密密钥,或者缺少适当的密钥管理或密钥回传。加密密钥提交到源代码存储库。
- 未执行强制加密,缺少安全相关的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。
- 单独验证每个安全配置项的有效性。
- 范例
- 读取解密的加密数据时被攻击
- 攻击HTTPS降级为HTTP盗取用户会话cookie,或中间人攻击
- 简单加密被破解
3. 注入 Injection
- 常见CWE
- 跨站点脚本
- SQL注入
- 文件名或路径的外部控制
- 风险说明
- 应用程序不会验证、过滤或清洗用户提供的数据。(对输入无过滤)
- 动态查询或无上下文感知转义的非参数化调用直接在解释器中使用。
- 恶意数据在对象关系映射(ORM)搜索参数中用于提取额外的敏感记录。
- 恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据。
- 预防措施
防止注入需要将数据与命令和查询分开
- 推荐的选择是使用安全的API,这样可以避免完全使用解释器、提供参数化接口或迁移到对象关系映射工具(ORM)。注意:即使参数化,如果PL/SQL或T-SQL将查询和数据连接起来,或者使用EXECUTE IMMEDIATE或exec()执行恶意数据,则存储过程仍然可以引入SQL注入。
- 使用肯定(positive)或“白名单”服务器端输入验证。这并不是一种完美的防御,因为许多应用
程序需要特殊字符,例如移动应用程序中的文本区域或API。 - 对于任何残余的动态查询,请使用该解释器的特定转义语法转义特殊字符。注意:SQL结构(如表名、列名等)无法转义,因此用户提供的结构名是危险的。这是报表编写软件中的常见问题。(转义特殊字符)
- 在查询中使用LIMIT和其他SQL控件,以防止在SQL注入的情况下大量披露记录。(限制查询范围)
4. 不安全设计 Insecure Design
- 常见CWE
- 生成包含敏感信息的错误消息
- 凭证的未保护存储
- 信任边界冲突
- 凭证保护不足
- 风险说明
缺少或无效的控制设计。
-
预防措施
- 使用安全的开发生命周期
- 对关键身份验证、访问控制、也无法逻辑和密钥流使用威胁模型。
- 编写单元和集成测试。
- 限制用户或服务的资源消耗
5. 安全配置错误 Security Misconfiguration
- 常见CWE
- XML外部实体引用的不当限制
- 风险说明
- 应用程序栈的任何部分缺少适当的安全加固,或者云服务的权限配置错误。
- 应用程序启用或安装了不必要的功能(例如:不必要的端口、服务、网页、帐户或权限)。
- 默认帐户和密码仍然可用且没有更改。
- 错误处理机制向用户纰漏堆栈信息或其他大量错误信息。
- 对于升级的系统,最新的安全特性被禁用或未安全配置。
- 应用程序服务器、应用程序框架(如:Struts、Spring、ASP.NET)、库文件、数据库等没有进 行安全配置。
- 服务器不发送安全标头或指令,或未被设定安全参数。
- 您的应用软件已过期或易受攻击(参见“A6:2021-脆弱和过时的组件”)。
- 预防措施
- 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置,并且在每个环境中使用不同的密码。这个过程应该是自动化的,以尽量减少安装一个新安全环境的耗费。
- 搭建最小化平台,该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
- 检查和修复安全配置项来适应最新的安全说明、更新和补丁,并将其作为更新管理过程的一部分(参见“A6:2021-脆弱和过时的组件”)。在检查过程中,应特别注意云存储权限(如:S3桶权限)。
- 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构,包括:分段、容器化和云安全组(ACL)。
- 向客户端发送安全指令,例如:安全标头。
- 一个能够验证所有环境中进行了正确的安全配置和设置的自动化过程。
- 示例
- 样例未删除,且样例存在安全漏洞。
- 目录列表在服务器端未被禁用。
- 已知含有漏洞的组件的版本信息。
- 云服务提供商向其他CSP用户提供默认的网络共享权限。
6. 自带缺陷和过时的组件 Vulnerable and Outdated Components
使用未维护第三方组件
- 风险说明
- 如果您不知道所有使用的组件版本信息(包括:服务端和客户端)。这包括了直接使用的组件或间 接依赖的组件。
- 如果软件易受攻击,不再支持或者过时。这包括:系统、Web服务器、应用程序服务器、数据库 管理系统(DBMS)、应用程序、API和所有的组件、运行环境和库。
- 如果您没有定期做漏洞扫描和订阅使用组件的安全公告。
- 如果您不基于风险及时修复或升级底层平台、框架和依赖库。很可能发生这种情况:根据变更控制, 每月或每季度进行升级,这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。
- 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。
- 如果您没有对组件进行安全配置(参见“A05:2021–安全配置错误”)。
- 预防措施
应制定一个补丁管理流程
- 移除不使用的依赖、不需要的功能、组件、文件和文档。
- 利用如versions、OWASP Dependency Check、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE和NVD等是否发布已使用组件的漏洞信息,可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。
- 仅从官方渠道安全的获取组件,并使用签名机制来降低组件被篡改或加入恶意漏洞的风险 (参见“A08:2021-软件和数据完整性故障”)。
- 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁,可以考虑部署虚拟补丁来监控、检测或保护。
7. 身份识别和身份验证错误 Identification and Authentication Failures
无效的身份认证,现在包含了与身份识别失效
- 常见CWE
- 与不匹配 的服务端进行不适当的凭证确认
- 不适当的认证
- 会话固定攻击
- 风险说明
- 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击。
- 允许暴力或其他自动化攻击。
- 允许预设、脆弱、常见的密码,像是”Password1″或”admin/admin”。
- 使用脆弱或无效的认证资讯回复或忘记密码的流程,如不安全的”知识相关问答”。
- 使用明码、被加密的或使用较脆弱杂凑法的密码(参考A3: 2017-敏感性资料泄漏)。(TODO)
- 不具有或是无效的多因素认证。
- 于URL中泄漏会话(session) ID(如URL重写)。
- 成功登入后没有轮换会话(session) ID。
- 没 有 正 确 的 注 销 会 话 (session) ID。用 户 的 会 话(session)或认证tokens(主要是单一登入)(SSO)token) 没有在登出时或一段时间没活动时被适当的注销
- 预防措施
- 在可能的情况下,实施多因素认证来防止自动化撞库攻击、暴力破解、以及遭窃认证资讯被重复
利用的攻击。 - 不要交付或部署任何预设的认证凭证,特别是管理者。
- 实施弱密码的检查,如测试新设定或变更的密码是否存在于前10000个最差密码清单。
- 将密码长度、复杂度和轮换政策与NIST 800-63b文件“第5.1.1节-被记忆的秘密或其他现代基于证据的密码政策”的内容保持一致。
- 对所有结果使用相同的讯息回应,确保注册、认证凭据回复以及API路径能够抵御帐号枚举击。
- 限制或增加登入失败尝试的延迟。记录所有失败并于侦测到撞库、暴力破解或其他攻击时发出告警。
- 使用服器端、安全的内建会话管理器,在登入后产生有高熵值的新随机会话ID。会话ID不应出现在URL中,必须被安全的储存,并且在登出后、闲置、超时后被注销。
- 在可能的情况下,实施多因素认证来防止自动化撞库攻击、暴力破解、以及遭窃认证资讯被重复
- 范例
- 撞库
- 弱口令
- 无会话超时,被盗用cookie
8. 软件和数据完整性故障 Software and Data Integrity Failures
未验证完整性的情况下做出与软件更新、关键数据和 CI/CD管道相关的假设。
- 常见CWE
- 包含来自不受信任控制领域的功能
- 不进行完整性检查的代码下载
- 不可信数据的反序列化
- 风险说明
软件和数据完整性故障与无法防止违反完整性的代码和基础设施有关。这方面的一个例子是, 应用程序依赖于不受信任的源、存储库和内容分发网络(CDN)的插件、库或模块。不安全的 CI/CD管道可能会带来未经授权的访问、恶意代码或系统安全风险。最后,许多应用程序现在包括 自动更新功能。其中,更新包在没有进行充足完整性验证的情况下被下载,并应用于以前受信任的应用程序。攻击者可能会上传自己的更新包,以便在所有安装上分发和运行。另一个例子是,对象或数据被编码或序列化为攻击者可以看到和修改的结构,很容易受到不安全的反序列化的影响。
-
预防措施
- 使用数字签名或类似机制来验证软件或数据来自预期来源,且未被修改。
- 确保库和依赖项目,如:npm 或 Maven,正在使用受信任的存储库。如果您的风险较高,请考虑 托管一个经过审核的、内部已知合格的存储库。
- 确保使用软件供应链安全工具(如:OWASP Dependency Check 或 OWASP CycloneDX)来验证组件不包含已知漏洞。
- 确保对代码和配置更改进行审核,以最大限度地减少恶意代码或配置引入软件管道的可能性。
- 确保您的CI/CD管道具有适当的隔离、配置和访问控制,以确保代码在构建和部署过程中的完整性。
- 确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播,所有未签名或 未加密的序列化数据不会发送到不受信任的客户端。
- 范例
- 无需签名即可更新(IoT固件更新)
- 恶意更新
- 不安全的反序列化
9. 安全日志和监控故障 Security Logging and Monitoring Failures
- 常见CWE
- 日志记录不足
- 日志输出不当
- 安全事件漏报
- 在日志文件中包含敏感信息
- 风险说明
帮助检测、升级和应对活跃的违规行为。如果不进行日志记录和监测,就无法发现违规行为。任何时候都会发生日志记录、检测、监视和主动响应不足的情况。
- 需要审计的事件,例如:登录、失败的登录和高价值交易,但未记录。
- 警告和错误未生成日志或日志记录不充分或日志消息不清晰。
- 应用程序和 API的日志未进行安全可疑活动的监控。
- 日志只存储在本地。
- 适当的警报阈值和响应升级过程不到位或无效。
- 渗透测试和动态应用安全测试(DAST)工具(例如:OWASP ZAP)的扫描没有触发警报。
- 应用无法实时或接近实时地检测、升级或或对主动攻击发出警报。
- 如果让用户或攻击者看到日志和警报事件,您就容易受到信息泄露的攻击(查看“A01:2021-失效的访问控制”)。
- 预防措施
- 确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在足够的用户上下文中,以识别 可疑或恶意的帐户,并保留足够的时间以允许延迟的取证分析。
- 确保日志是日志管理解决方案以方便使用的格式生成的。
- 确保日志数据被正确编码加密,以防止对日志或监控系统的注入或攻击。
- 确保高价值交易有完整性控制的审计跟踪,以防止篡改或删除,例如:只附加数据库表或类似的内容。
- DevSecOps团队应该建立有效的监控和警报,以便发现可疑的活动并迅速做出反应。
- 建立或采用事故应对和恢复计划,例如:美国国家标准技术研究所(NIST)800-61r2或更高版本。
- 有一些商业和开源的应用程序保护框架,如:OWASP ModSecurity核心规则集,以及开源的日 志相关软件,如:Elasticsearch、Logstash、Kibana(ELK),具有自定义仪表盘和告警功能。
- 攻击
- 泄露隐私数据
10. 服务端请求伪造 Server-Side Request Forgery
- 风险说明
一旦Web应用在获取远程资源时没有验证用户提供的URL,就会出现SSRF缺陷。它允许攻击 者强制应用程序发送一个精心构建的请求到一个意外目的地,即使是在有防火墙、VPN或其他类型的网络访问控制列表(ACL)保护的情况下。
随着现代Web应用为终端用户提供便利的功能,获取URL成为一种常见的场景。因此,SSRF安全攻击事件也在不断增加。此外,由于云服务和架构的复杂性,SSRF的严重性也越来越高。
-
预防措施
纵深防御来阻止 SSRF
- 在隔离的网络中设置多个远程资源访问功能的网段,以减少SSRF的影响。
- 执行“默认拒绝”防火墙策略或网络访问控制规则,以阻止除必要的内部网通信外的所有通信。
- 建立基于应用的防火墙规则的所有权和生命周期。
- 在防火墙上记录所有接受和阻止的网络流。
- 应用层防御建议
- 检查和验证所有客户端提供的输入数据。
- 使用白名单允许列表允许列表执行URL统一资源标志符、端口和目标。
- 不要给客户端发送原始的回复。
- 禁用 HTTP 重定向。
- 注意URL的一致性,以避免DNS重新绑定和“检查时间,使用时间”(TOCTOU)竞争条件等攻击。
- 不要通过使用黑名单拒绝列表或正则表达式来缓解SSRF。攻击者拥有有效载荷列表、工具和绕过拒绝列表的技能。
- 需额外考虑的措施
- 不要在前端系统上部署其他与安全相关的服务(如:OpenID)。控制这些系统上的本地流量(如:localhost)。
- 对于专用和可管理的前端用户,可以在独立系统上使用网络加密(如:vpn)来满足非常高的安全保护需求。
- 范例
- 内部服务器端口扫描
- 敏感数据泄露file:///etc/passwd
- 访问云服务的元数据存储http://169.254.169.254/
- 危害内部服务(RCE、DoS)
附录: The CWE Top 25
- 越界写入 Out-of-bounds Write
- XSS跨站脚本攻击 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
- 越界读取 Out-of-bounds Read
- 不适当的输入验证 Improper Input Validation
- 操作系统命令注入 Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
- SQL注入 Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
- 释放后重用 Use After Free
- 路径遍历 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
- 跨站请求伪造 Cross-Site Request Forgery (CSRF)
- 文件上传 Unrestricted Upload of File with Dangerous Type
- 缺少关键功能的身份验证 Missing Authentication for Critical Function
- 整数溢出或环绕 Integer Overflow or Wraparound
- 反序列化 Deserialization of Untrusted Data
- 不适当的认证 Improper Authentication
- 空指针 NULL Pointer Dereference
- 使用硬编码的凭据 Use of Hard-coded Credentials
- 内存缓冲区范围内的操作限制不当 Improper Restriction of Operations within the Bounds of a Memory Buffer
- 缺少授权 Missing Authorization
- 默认权限不正确 Incorrect Default Permissions
- 将敏感信息暴露给未经授权的行为者 Exposure of Sensitive Information to an Unauthorized Actor
- 保护不足的凭据 Insufficiently Protected Credentials
- 关键资源的权限分配不正确Incorrect Permission Assignment for Critical Resource
- XML 外部实体引用的不当限制(XXE)Improper Restriction of XML External Entity Reference
- 服务器端请求伪造 Server-Side Request Forgery (SSRF)
- 命令注入 Improper Neutralization of Special Elements used in a Command (‘Command Injection’)
参考文档
【1】OWASP-TOP10-2021中文版V1.0发布.pdf