什么是 OWASP Top 10?

OWASP(Open Worldwide Application Security Project,开放全球应用程序安全项目)是一个致力于提高软件安全性的非营利性组织,其提供 Web 应用程序安全领域的标准、工具和指导手册,被业界大量的企业作为权威来参考。

OWASP Top 10 是 OWASP 组织定期更新的一份风险报告,其由世界各地的安全专家整理而成,重点关注 Web 应用程序安全领域的 10 个最关键的风险或漏洞。这些风险或漏洞是所有企业都应当重视和规避的。

写作本文时,OWASP Top 10 的最新版本是 2021,本文将对其列出的 10 大风险作一一介绍。

1 失效的访问控制

失效的访问控制为收集的数据集中名列第一的风险。需要注意的 CWE(Common Weakness Enumerations,通用缺陷列表)有:将敏感信息暴露给未经授权的参与者(CWE-200)、将敏感信息插入到发送数据(CWE-201)和跨站请求伪造(CWE-352)。

有效的访问控制是保证用户只能执行所拥有权限内的操作,不能执行所拥有权限外的任何操作。失效的访问控制通常会造成未经授权的信息泄露。

常见的漏洞包括:

  • 违反最小权限原则或默认拒绝原则,即访问权限应只授予特定的角色,但实际上任何人都可以访问;
  • 通过修改 URL 或 HTML 页面来绕过访问控制检查;
  • 知道了对方的 ID,即可以查看或编辑他人的账户;
  • API 没有对 POST、PUT 和 DELETE 方法进行有效的访问控制;
  • 特权提升,即在未登录的情况下假扮特定用户,或在以普通用户身份登录时假扮管理员;
  • 元数据操作,诸如篡改或操纵 JWT(JSON Web Token)访问控制令牌、Cookie 以及隐藏字段来进行特权提升;
  • CORS(Cross-origin Resource Sharing,跨域资源共享)错误配置允许来自不可信来源的 API 访问;
  • 以未经身份验证的用户身份浏览需要身份验证的页面或以标准用户身份浏览特权用户页面。

预防措施:

须在服务端进行有效的访问控制,从而保证攻击者无法绕过检查或篡改数据。

  • 除公共资源外,一律默认拒绝访问;
  • 实现统一的访问控制机制并在整个应用程序中进行重用,减少跨域资源共享 (CORS) 的使用;
  • 访问控制模型应细粒度控制用户与记录的权限,而不应让用户对任何记录都可以进行增删改查;
  • 独特的应用程序业务限制需求应由域模型来进行强化;
  • 禁用 Web 服务器目录查看并确保 Web 根目录不包含文件元数据(如 .git)和备份文件;
  • 在日志中记录失效的访问控制,并在超过一定重复次数时向管理员告警;
  • 对 API 调用进行速率限制,以减少自动化攻击工具的危害;
  • 登出时有状态会话标识应当在服务器端失效;对于无状态的 JWT,登出时应遵循 OAuth 标准来撤销访问权限。

此外,开发人员与 QA(Quality Assurance,质量保证)人员应在单元测试和集成测试中对访问控制进行功能测试。

2 加密机制失效

加密机制失效为收集的数据集中名列第二的风险,以前被称为「敏感数据泄漏」,但这种描述更像是问题的表现而不是根本原因,根因是与密码学相关的加密机制失效。需要注意的 CWE 有:使用硬编码的密码(CWE-259)、失效或有风险的加密算法(CWE-327)和信息熵不充分(CWE-331)。

首先需要确认:对于传输数据和存储数据都有哪些保护需求。如密码、信用卡号、健康记录、个人信息和商业秘密一般需要额外的保护。

对于这些数据,需要确认:

  • 传输过程中是否使用了明文?除了需要严格避免其在外部网络明文传输之外,在内网依然需要验证其在各负载均衡器之间、Web 服务器之间以及后端系统之间是否使用了明文传输?
  • 代码中是否使用了弱的加密算法或传输协议?
  • 收到的服务器证书和信任链是否经过有效验证?
  • 是否仍在使用 MD5 或 SHA1 等已弃用的哈希函数,或者在需要加密哈希函数时是否使用了非加密哈希函数?
  • 是否仍在使用已弃用的加密填充方法,例如 PKCS v1.5?

预防措施:

  • 对被应用程序处理的、存储的或传输的数据进行分类,并根据法律法规要求或业务需求确定哪些数据是敏感数据;
  • 非必要情况下不存储敏感数据或者适时对敏感数据进行清除;
  • 确保加密存储所有的敏感数据;
  • 确保使用了最新的、最强的算法、协议和密钥,并对密钥进行妥善的管理;
  • 使用安全协议(如 TLS,Transport Layer Security,传输层安全)来传输数据;
  • 禁止对包含敏感数据的响应进行缓存;
  • 根据数据的分类进行所需的安全控制;
  • 不要使用 FTP(File Transfer Protocol,文件传输协议) 和 SMTP(Simple Mail Transfer Protocol,简单邮件传输协议)等旧协议来传输敏感数据;
  • 使用具有工作因子的强自适应和加盐哈希函数(如 Argon2、scrypt、bcrypt 或 PBKDF2)来存储密码;
  • 始终使用经过身份验证的加密,而不仅仅是加密;
  • 密钥应以加密方式随机生成,并作为字节数组存储在内存中;如果使用密码,则必须通过适当的密码基密钥派生函数将其转换为密钥;
  • 确保在适当的地方使用加密随机性,并且它没有以可预测的方式或低熵播种;
  • 避免使用弃用的加密函数和填充方案,例如 MD5、SHA1、PKCS v1.5;
  • 独立验证配置和设置的有效性。

3 注入

注入为收集的数据集中名列第三的风险。需要注意的 CWE 有:跨站点脚本(CWE-79)、SQL 注入(CWE-89)和文件名或路径的外部控制(CWE-73)。

应用程序在如下情况易受到攻击:

  • 应用程序未对用户提供的数据进行校验、过滤和清洗;
  • 动态查询或无上下文感知转义的非参数化调用直接在解释器中使用;
  • 在 ORM(Object Relational Mapping,对象关系映射)搜索参数中使用恶意数据来提取额外的敏感记录;
  • 直接使用或连接恶意数据,SQL(Structured Query Language,结构化查询语言)或命令包含动态查询、命令或存储过程中的结构和恶意数据。

常见的注入有:SQL 注入、NoSQL(Not Only SQL,非结构化查询语言)注入、OS(Operating System,操作系统)命令注入、ORM 注入、LDAP(Lightweight Directory Access Protocol, 轻型目录访问协议)注入、EL(Expression Language,表达式语言)注入和 OGNL(Object Graph Navigation Language,对象图导航语言)注入。

Code Review(源代码审查)是检测应用程序是否易受注入威胁的最佳方法。建议将请求参数、请求头、Cookie、JSON 请求体、SOAP 数据体和 XML 数据体进行自动化测试。此外,还建议在 CI/CD(Continuous Integration and Continuous Delivery,持续集成和持续交付)流水线中加入 SAST(Static Application Security Testing,静态应用安全测试)、DAST(Dynamic Application Security Testing,动态应用安全测试)和 IAST(Interactive Application Security Testing,交互式应用安全测试)等多种安全测试来提前发现可能的注入风险。

预防措施:

  • 首选方案是使用安全的 API(避免完全使用解释器、提供参数化接口、规范使用 ORM 工具);
  • 对于任何残留的动态查询,对解释器使用特定的转义语法来转义特殊字符;
  • 在查询中使用LIMIT或其它 SQL 控件,以防止在 SQL 注入的情况下大量泄露记录。

4 不安全的设计

这是 2021 版的一个新类别,侧重于设计和架构相关的风险,呼吁更多的使用威胁建模、安全设计模式和参考架构。需要注意的 CWE 有:生成包含敏感信息的错误消息(CWE-209)、凭证存储保护不足(CWE-256)、违反信任边界(CWE-501)和凭证保护不足(CWE-522)。

预防措施:

  • 与应用程序安全专家一起建立安全的开发生命周期以评估和设计与安全和隐私相关的控制措施;
  • 使用安全设计模式库或使用安全组件;
  • 在身份验证、访问控制和关键流程或业务逻辑中使用威胁建模;
  • 将安全控制集成到用户故事中;
  • 从前端到后端在应用程序的每一层集成合理性检查;
  • 编写单元测试和集成测试以验证所有关键流程是否都能抵抗威胁模型;
  • 根据暴露需求和保护需求,在系统层和网络层上分离层级;
  • 在所有层上进行租户隔离;
  • 限制用户和服务的资源消耗。

5 安全配置错误

因安全配置错误引起的风险较之前呈上升的趋势。需要注意的 CWE 有:配置(CWE-16)、XML 外部实体引用限制不当(CWE-611)。

易受到攻击的配置:

  • 应用程序栈各部分缺少适当的安全加固,或者云服务的权限配置不当;
  • 启用或安装了不必要的特性(如:开放了不必要的端口、服务、页面、账户或权限);
  • 仍在使用默认账号和密码;
  • 暴露给用户堆栈信息或其它大量的错误信息;
  • 对于升级的系统,最新的安全功能被禁用或未安全配置;
  • 应用程序服务器、应用程序框架(例如 Struts、Spring、ASP.NET)、库或者数据库等的安全设置配置的值不正确。

如果没有一致的、可重复的应用程序安全配置过程,系统就会面临更高的风险。

预防措施:

  • 可重复的加固过程可以快速轻松地部署一个安全的环境,如使用自动化流水线来部署开发、QA 和生产环境;
  • 应部署一个没有任何不必要特性、组件、文档和示例的最小平台;
  • 作为补丁管理流程的一部分,审查和更新适用于所有安全说明、更新和补丁的配置的任务;
  • 使用分段应用程序架构在组件或租户之间进行分段、容器化以提供有效且安全的分离;
  • 向客户端发送安全指令,例如安全头;
  • 使用自动化流水线来验证所有环境中的配置和设置的有效性。

6 自带缺陷和过时的组件

自带缺陷和过时的组件是一个已知问题。需要注意的 CWE 有:使用未维护的第三方组件(CWE-1104)。

若存在如下情形,则易受到攻击:

  • 不知道所使用的所有组件的版本(客户端和服务器端),包括直接使用的组件以及嵌套的依赖项;
  • 软件易受攻击、不受支持或已过时,这包括操作系统、应用程序服务器、数据库管理系统、应用程序、API 和所有组件、运行时环境和库;
  • 未定期扫描漏洞或未订阅所使用组件的安全公告;
  • 未基于风险的方式及时修复或升级底层平台、框架和依赖项;
  • 软件开发人员不测试更新、升级或修补库的兼容性。

预防措施:

  • 删除未使用的依赖项、不必要的功能、组件、文件和文档;
  • 使用 OWASP 依赖性检查、retire.js 等工具持续清点客户端和服务器端组件及其依赖项的版本,并检查是否存在漏洞;
  • 仅通过安全链接从官方来获取组件;
  • 监控已不再维护的组件。

7 身份识别和验证失效

之前被称为「无效的身份验证(Broken Authentication)」。需要注意的 CWE 有:含主机不匹配的证书验证不当(CWE-297)、身份验证不当(CWE-287)和会话固定(CWE-384)。

确认用户身份、身份验证和会话管理对于防治与身份验证相关的攻击至关重要。

若存在如下情形,则易受到攻击:

  • 允许像是攻击者已经拥有有效用户名和密码列表的试错自动化攻击;
  • 允许蛮力自动攻击;
  • 允许默认密码、弱密码或众所周知的密码,如「123456」;
  • 使用薄弱的忘记密码恢复过程,例如设置「大众皆知的问题和答案」;
  • 使用纯文本或弱哈希密码数据存储;
  • 完全没有或使用了不是很有效的多重身份验证;
  • 在 URL 中暴露会话 ID;
  • 成功登录后重用之前旧的会话标识符;
  • 登出后未将会话 ID 失效。

预防措施:

  • 在可能的情况下,实施多因素身份验证以防止自动凭据填充、暴力破解和被盗凭据重用攻击;
  • 不要带着默认凭据进行部署,特别是对于管理员用户;
  • 实施弱密码检查,如测试用户设置的密码是否在 10000 个常用密码清单中;
  • 增大密码长度、增强复杂性并制定定期更换策略;
  • 对所有校验结果(如注册时和恢复时)使用相同的消息以防止账户枚举攻击;
  • 对多次失败登录进行记录并在检测到暴力破解时提醒管理员;
  • 服务器端在用户登录后生成一个新的具有高熵的随机会话 ID,且防止将其暴露到 URL,并在注销时将其失效。

8 软件和数据完整性故障

这是 2021 版的一个新类别,侧重于在不验证完整性的情况下进行软件更新的风险。需要注意的 CWE 有:包含不受信任控制范围的功能(CWE-829)、下载未经完整性检查的代码(CWE-494)和不可信数据的反序列化(CWE-502)。

若存在如下情形,则易受到攻击:

  • 应用程序依赖来自不受信任的来源提供的插件、库或模块;
  • 不安全的 CI/CD 流水线带来未经授权的访问或引入了恶意代码;
  • 应用程序包含自动更新功能,且在没有充分完整性验证的情况下进行下载更新;
  • 对象或数据被编码或序列化为攻击者可以看到和修改的结构,从而易受到不安全反序列化的影响。

预防措施:

  • 使用数字签名或类似机制来验证软件或数据来自预期来源;
  • 确保库和依赖项(例如 npm 或 Maven)使用了受信任的存储库;
  • 使用 OWASP Dependency Check 或 OWASP CycloneDX 等安全工具来验证组件不包含已知漏洞;
  • 对代码和配置更改进行审查,以最大限度地减少恶意代码被引入的可能性;
  • 确保 CI/CD 流水线具有恰当的访问控制,以确保代码的完整性;
  • 确保未签名或未加密的序列化数据不会发送到不受信任的客户端。

9 安全日志和监控故障

此类别旨在帮助检测与记录可能的违规行为,没有日志记录和监控,就无法检测到违规行为。需要注意的 CWE 有:日志伪造漏洞(CWE-117)、遗漏安全相关信息(CWE-223)和将敏感信息插入日志文件(CWE-532)。

若存在如下情形,则易受到攻击:

  • 审计性事件未被记录,如登录、登录失败和大额交易;
  • 警告或错误信息不清晰;
  • 未对 API 日志中的可疑活动进行监控;
  • 日志仅存储在本地;
  • 未设置适当的报警阈值;
  • 无法实时对攻击进行告警。

预防措施:

  • 确保所有登录、访问控制和服务器端输入验证失败被合理的记录,从而识别可疑的行为;
  • 确保输出的日志清晰明了以能被监控系统轻松捕捉;
  • 确保日志数据正确编码,以防止对日志记录或监控系统进行注入或攻击;
  • 确保高额交易带有审计跟踪,以防止篡改或删除;
  • DevSecOps 团队应该建立有效的监控和警报,以便检测到可疑活动时能快速做出响应;
  • 制定事件响应和恢复计划。

10 服务端请求伪造

Web 应用程序在获取远程资源时没有验证用户所提供的 URL,就会出现服务端请求伪造(Server-Side Request Forgery,SSRF)风险。它允许攻击者即使受到防火墙、VPN 或 ACL (Access Control List,网络访问控制列表) 的保护下,强制应用程序也能发送一个精心构造的请求到一个意想不到的目的地。

预防措施:

  • 网络层

    • 为远程资源访问功能设置单独的网段,以减少 SSRF 的影响;
    • 应用「默认拒绝」防火墙规则,以阻止除必要的内部网络通信外的所有通信流量。
  • 应用层

    • 清洗和验证所有客户端输入;
    • 使用白名单列表控制放行 URL 的模式、端口和目标地址;
    • 不要向客户端发送原始响应;
    • 禁用 HTTP 重定向;
    • 注意 URL 一致性以避免 DNS 重新绑定和「检查时间/使用时间」(TOCTOU) 竞争条件等攻击;
    • 不要使用黑名单或正则表达式来缓解 SSRF,攻击者拥有绕过拒绝列表的技能。
  • 其它方面

    • 不要在前端系统上部署与安全相关的服务(如 OpenID),控制这些系统上的本地流量(如 localhost);
    • 对于专用前端用户,可在独立系统上使用网络加密技术(如 VPN)来满足高安全保护需求。

综上,本文首先介绍了什么是 OWASP,然后根据 2021 版的 OWASP Top 10 详细介绍了当前 Web 应用程序面临的十个排名最高的风险点。

参考资料

[1] OWASP | Wikipedia - en.wikipedia.org

[2] OWASP Top Ten | OWASP Foundation - owasp.org

[3] What is OWASP? What is the OWASP Top 10? | Cloudflare - www.cloudflare.com

[4] OWASP Top 10 2021 全新出炉 | 郑州市网络安全协会 - www.zzwa.org.cn

[5] OWASP—Top10(2021 知识总结)| CSDN 博客 - blog.csdn.net

评论

正在加载评论......