通过测试管理避免开源开发错误

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

开源 GnuTLS 加密库再次因安全漏洞而成为新闻,该漏洞可能会使许多 Linux 发行版用户面临遭受攻击的风险。在 OpenSSL 中的 Heartbleed 漏洞启用服务器传输的监视和窃取几个月后,这个问题就出现了。这也是继 3 月初发现 SSL/TLS 旁路漏洞之后,今年 GnuTLS 的第二次重大挫折。

开源软件开发具有独特的风险。许多涵盖各种技能水平的开发人员都为项目做出了贡献,但通常在经济上或其他方面很少有动力去不断审查代码是否存在安全风险。问题往往是事后才发现的。企业可以通过使用商业测试管理解决方案和测试指标来简化质量保证流程并确保高效协作,从而避免类似情况。

GnuTLS 漏洞可能会扰乱 HTTPS 请求

新的 GnuTLS 错误是在 5 月下旬发现的,并且已经被修补。但是,由于依赖它的数百个发行版以及它们实现它的各自方式,它们可能需要一些时间才能修复并使轮次和问题平息。

在技​​术层面上,该缺陷可以在建立 HTTPS 连接期间传递恶意数据,从而导致任意代码执行。总的来说,未打补丁的 GnuTLS 实施的用户可能容易受到偷渡式攻击,这种攻击除了可能发生崩溃外,不会发出任何迹象表明劫持正在进行。

“在 GnuTLS 从 TLS/SSL 握手的 ServerHello 消息中解析会话 ID 的方式中发现了一个缺陷,”Red Hat Bug Tracker 上的一篇帖子说。 “恶意服务器可以利用此缺陷发送过长的会话 ID 值,这会在使用 GnuTLS 的连接 TLS/SSL 客户端应用程序中触发缓冲区溢出,导致客户端应用程序崩溃或可能执行任意代码。”

目前尚不清楚该错误是否已在 GnuTLS 中存在一段时间或最近才引入。去年 3 月曝光的 GnuTLS 漏洞可能已经存在了将近九年,这表明即使在大型开源项目中也可能存在未被发现的重大缺陷。这使伪造证书的制造商能够让 GnuTLS 认为它们是合法的。

除了 GnuTLS 和 Heartbleed,开源 TrueCrypt 的创建者最近发布了一条警告,称他们的库不再安全。 Network Time Protocol、OpenSSL 和 OpenSSH 等主要项目虽然对一般互联网安全至关重要,但历来资金不足,由于时间和资金的限制而导致问题得不到解决的风险。 Network Time Protocol 和 OpenSSL 今年都受到了有针对性的利用。正是这些例子支持了拥有商业测试系统和测试指标是不可避免的论点

持续协作对于产品开发和软件测试行业的发展确实至关重要;这就是为什么它绝对需要坚实的技术和程序基础。重要的是要注意,只有一个强大的测试管理系统可以促进场景的轻松重用,以及通过 API 与各种工具集成,才能使项目协调高效。