OWASP Top 10漏洞解析（2）- A2:Cryptographic Failures 加密机制失效

news2024/11/25 22:29:31

作者：gentle_zhou

原文链接：OWASP Top 10漏洞解析（2）- A2:Cryptographic Failures 加密机制失效-云社区-华为云

Web应用程序安全一直是一个重要的话题，它不但关系到网络用户的隐私，财产，而且关系着用户对程序的新人。随着Web应用程序功能持续增加，复杂性不断提高，这些程序也面临着越来越多的安全威胁和挑战。

为了帮助这些应用程序的开发团队和安全人员了解和防范这些威胁，提高安全意识，编写更安全的代码，OWASP（Open Web Application Security Project，开放式Web应用程序安全项目）发布了一份标准指南，称为OWASP Top 10。

这是一份关于Web应用程序安全风险的标准指南，它基于全球范围内的安全专家和数据提供者的共识，列出了当前最严重、最关键的10种Web应用程序安全风险，并提供了相应的防范措施和建议。OWASP Top10 每隔几年会更新一次（目前已经发布了六个版本，分别是2004年、2007年、2010年、2013年、2017年和2021年），最新的版本是在2021年发布的OWASP Top10:2021。

已解析的OWASP漏洞

OWASP Top 10漏洞解析（1）- A1:Broken Access Control 访问控制失效：OWASP Top 10漏洞解析（1）- A1:Broken Access Control 访问控制失效-云社区-华为云

“加密机制失效”缺陷详情

今天，就来为大家讲解其中的第二条缺陷：Cryptographic Failures加密机制失效，它从2017年版本的第3位上升到了当前第2位。

在之前的版本中，该类缺陷被称为“敏感数据泄漏”（Sensitive Data Exposure），这听上去更像是一种症状/结果而并非是缺陷根因。而在新版本里，则更聚焦于密码学相关的失效（或则说加密机制的缺乏），而这类失效则常常会导致敏感数据的泄漏。典型的CWE漏洞包括：CWE-259：使用了硬编码密码，CWE-327：使用了已被破坏或有风险的密码算法和 CWE-331：不充分的熵（entropy，每条消息中包含的信息量）。

对于这类缺陷，用户需要首先决定数据在包括传输等一系列过程中的保护需求；举个例子，这里说的数据可以是密码，信用卡卡号，健康记录，个人信息，需要额外保护的商业秘密等，简单来说被隐私法所保护的数据，比如欧盟的GDPR，金融行业数据保护相关（比如PCI数据安全标准）。

常见的加密机制失效缺陷类型

对于数据，是否存在加密机制失效的缺陷，可以从这几方面去考虑：

是否以明文的形式传输了数据，包括 HTTP, SMTP, FTP 等协定？互联网路中明文传输数据是危险的。我们必须验证所有的内部流量，比如负载均衡器，网站服务器，或则后端系统之间。
是否默认或则在先前写的代码中，使用了任何老旧或则脆弱的加密算法或协议？
是否正在使用默认的加密秘钥，是否生成或则重复使用了弱加密秘钥，是否缺失了合适的秘钥管理或轮换？是否把加密秘钥写入了源代码仓库中？
是否没有强制执行加密举措？比如说，是否有任何浏览器中的HTTP头缺失了安全相关的指令或头信息？
是否适当地验证了收到的服务器证书和信任链可信？
初始化向量是否被忽略，重复使用，或则没有为密码学操作生成充分安全的初始化向量？是否使用了诸如ECB这样的不安全的操作模式？是否在使用认证加密更合适的场景下，使用了未认证加密？
是否在没有密码基础的密钥派生函数内，使用了密码作为密码学密钥？
是否使用了不符合密码学要求的随机数来满足加密要求？即使选择了正确的函数，它是否需要由开发者来设置seed信息；如果不需要，开发者是否使用了一个缺乏充分验证/具有不可预测性的seed替代覆盖了原有的内置的强seeding功能？
是否使用了已弃用的哈希函数，如MD5或SHA1，或者在需要密码学哈希函数的情况下使用了非密码学哈希函数？
是否使用了已弃用的密码学填充方法，比如如PKCS number 1 v1.5？

如何防止该缺陷的发生

最低程度，至少需要做到如下这些事情：

使用APP应用程序来分类数据是否已被处理、存储或传输。根据隐私法律、监管要求或商业需求，来确认哪些数据是敏感的
不要不必要地去存储敏感数据。对于非必要数据，需要尽快丢弃或使用符合PCI DSS标准对其令牌化或甚至截断。我们需要明确的是，没有保留的数据不会被偷窃
确保加密了所有敏感数据
确保在适当的地方使用最新和强大的标准算法、协议和密钥；使用适当的密钥管理机制
使用安全协议（比如TLS）加密所有传输中的数据，使用具有前向保密（FS）密码、服务器优先的密码和安全参数。使用诸如HTTP严格传输安全（HSTS）之类的指令来强制加密
禁用包含敏感数据响应的缓存
根据数据分类来应用所需的安全控制
不要使用遗留协议（比如FTP, SMTP）来传输敏感数据
使用具有工作因子（延迟因子）的强适应性和加盐的哈希函数来存储密码，例如Argon2，scrypt，bcrypt或PBKDF2
初始化向量必须根据操作模式来适当地选择。对于许多模式，这意味着使用CSPRNG（密码学安全伪随机数生成器）。对于需要nonce的模式，那么初始化向量（IV）不需要CSPRNG。在所有情况下，对于固定密钥，IV都不应该重复使用
始终使用认证加密而不仅仅是加密
秘钥应该以密码学随机的方式生成，并以字节数组的形式存储在内存中。如果使用密码，则必须通过适当的密码基础密钥派生函数将其转换为密钥。
确保在适当的地方使用密码学随机性，并且没有以可预测的方式或低熵进行seed设置。大多数现代API不要求开发者为了获得安全性而设置CSPRNG的种子。
避免使用已弃用的密码学函数和填充方案，如MD5，SHA1，PKCS number 1 v1.5。
独立验证配置和设置的有效性。

举个栗子

场景1

一个应用程序使用自动的数据库加密法来加密数据库中的信用卡号。然而，当检索这些数据时，它们会自动解密，从而让SQL注入漏洞有了可趁之机：会以明文形式获取到这些信用卡号。

场景2

一个网站没有使用或强制所有页面使用TLS，或者使用了弱加密。
一个攻击者可以监控网络流量（例如，在一个不安全的无线网络中），将连接从HTTPS降级到HTTP，拦截请求，并窃取用户的会话cookie。然后，攻击者可以重新使用这个cookie并劫持用户的（已认证的）会话，从而可以访问或修改用户的私有数据。除了上述情况，攻击者还可以修改所有传输的数据，例如，转账的收款人。