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

作者: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漏洞

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

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

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

OWASP Top 10漏洞解析(2)- A2:Cryptographic Failures 加密机制失效_第1张图片

在之前的版本中,该类缺陷被称为“敏感数据泄漏”(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并劫持用户的(已认证的)会话,从而可以访问或修改用户的私有数据。除了上述情况,攻击者还可以修改所有传输的数据,例如,转账的收款人。

场景3

密码数据库使用不加盐或简单的哈希来存储每个人的密码。
一个文件在上传过程中有的漏洞允许攻击者获取密码数据库。所有不加盐的哈希都可以通过预先计算的哈希的彩虹表来暴露。由简单或快速哈希函数生成的哈希可能会被GPU破解,即使它们被加盐了。

参考链接

1、https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

体验华为云CodeArts Check 代码检查服务:代码检查CodeArts Check_精准定位_代码缺陷_安全检查_华为云

你可能感兴趣的:(安全,网络,web安全)