证明网站上运行的代码没有改变

信息安全 哈希 证书 电子签名 源代码
2021-09-01 12:02:38

是否可以向用户证明带有安全相关代码的网站背后的运行代码与发布的相同?

我目前正在研究一些新的项目创意,其中一个涉及安全通信。我想让它开源,以便用户可以查看,更重要的是安全专家。这可能会成功证明所提供的代码是安全的,但是如何确保用户确信这个经过审查的代码确实在网站上运行?

我曾想过提供一种文件的散列值来完成与安全相关的工作并将其打印出来,但该散列值很容易被静态打印,因此无法提供真正的确定性。使用可以从已发布的源代码编译并比较的应用程序进行此操作很容易,但不适用于网站。证书可能只证明谁在运营该网站,但他们不知道该运营商是否值得信任。

任何类型的用户都可以放心吗?

4个回答

事实上,没有人能真正证明一个系统完全不受所有攻击的影响。 可证明的安全性永远不可能真正完美,因为定期开发新的攻击。安全是一个新领域,我们并不真正了解软件可能被滥用的所有方式。为了安全起见,有些项目是开源的,这样做有两个主要原因。

一些公司“众筹”他们的安全性并提供漏洞赏金计划。Mozilla 是这种模式最成功的公司之一,他们所有的应用程序和基础设施都是开源的。我在他们的基础设施中发现了四个关键漏洞,我为这些发现筹集了 3,000 美元。我很高兴我能够让 Mozilla 更安全。在不容易的地方收集这些赏金,错误赏金计划使寻找错误成为一场激烈的竞争。

还有一些项目将他们的应用程序的一部分开源,这样他们的用户就可以相互依赖地验证软件实际上是安全的。Whisper Systems(现在是 twitter 的一部分)和他们的移动产品RedPhone就是很好的例子。出于这个原因HushMail 的部分内容也是开源的。

我不确定这是否适用于您的具体问题或情况,但它适用于问题的标题我将其作为答案发布在这里,因为未经授权的代码(通常)使其成为网络服务器的问题在我所知道的任何指导中都没有很好地涵盖。我希望这个答案能帮助与我们的情况比你更相似的其他人。


您不能 100% 确定,但由工具增强的安全开发生命周期可以大大有助于提供帮助。它可能是劳动密集型的,并且涉及手动检查日志,或者至少是一些人工交互,但是如果您有敏感数据,并且有实施任何方法的预算,那么 IMO 值得付出努力。

我们有一个适当的流程来帮助确保发布到我们服务器的代码是经过批准和审查的代码。我不会列出任何产品,但这里是我们的程序和政策的概要:

政策:

  1. 开发人员无权访问实时系统,期间。开发人员无法将代码推送到服务器。代码需要由开发之外的指定团队推送。
  2. 跟踪所有更改(源代码控制)
  3. 所有更改必须在发布之前进行审核。(并且审查由审查人员和开发人员记录和签署。)
  4. 代码审查指定了批准发布的特定源代码修订版本号。
  5. 发布代码的团队通过自动构建/部署脚本直接从源代码控制发布代码。他们只是提供修订号和标签。该脚本负责从源代码控制中的正确位置获取代码并将其推送到实时服务器。他们不知道该怎么做。

有助于执行此操作的工具:

  • 我们的网络服务器上运行着记录任何文件更改的软件。
    • 代码更改会向我们的安全管理员发出标记,他们会检查以确保更改已被流程批准、审查和实施
    • 这有助于我们捕获可能通过流氓内部人员或通过某些代码上传进入服务器的代码。
  • 我们还有可以比较文件/目录差异的软件。可能的工具在这里)这些工具可用于扫描“已知良好”的一组已发布代码,并将它们与我们的实时服务器进行比较。在这种情况下,“已知良好”是直接来自源代码控制的经过审查/批准的修订版中的代码。
    • 其中许多工具都可以编写脚本。
    • 我们还没有实现这一点,但我们正在考虑构建服务器配置的想法,该配置将从源代码控制中检查代码并使用脚本自动进行比较,如果检测到差异,则通过电子邮件发送指定的人。在纸面上,我们已经想出了如何做到这一点,但还没有开始测试/实现它。

当然,这不是我们开发/风险管理/部署过程的全部,但它确实突出了确保批准的代码在我们的实时服务器上实际到位的部分。我忽略了持续的自动化渗透测试,以及我们采用的一系列其他对策,以尽量减少对客户的风险。

这也不是万无一失的。有坚定的攻击者可以利用的漏洞。例如,如果我们的管理员实际上并未审核更改以确保其获得批准,则该流程将无法正常工作。此外,显然存在时间滞后 - 安全人员无法 24/7 全天候监控更改,因此如果他或她不在身边,那么有人可能会在服务器上获得未经授权的代码,并且它会一直存在,直到管理员重新开始工作。

作为替代方案,我们玩弄了一个简单的想法,即让构建服务器每隔 x 小时从一个预先确定的、预先批准的标签自动发布整个网站。这样,即使有错误的代码出现,它也会每 x 小时自动删除一次。但是这种方法存在明显的问题,我们还没有准备好走这条路。

很可能我们所有的工作都是愚蠢的,而且我们做错了,但是对于这个特定的问题没有太多的指导,我们只能尽力而为。这个过程也基于我们的特定环境和商业模式。(维护我们自己的网站、自托管、整个开发团队、业务部门和网络管理员都在内部。)它可能不适用于处于不同情况的任何人。希望其他人有其他更有效且效果更好的方法。

因此,与其他答案一致,没有 100% 万无一失的方法来确保未经授权的代码可以进入服务器。但这不应该阻止你尽你所能。而且,如果您可以记录并向用户证明您正在做某事,那么您将大大有助于建立他们的信任。如果您对计划/流程中的潜在漏洞诚实,您可能会进一步获得他们的信任。关键是在理性、预算、时间和可用工具的限制下,尽你所能。

没有像散列函数这样的技术工具可以提供您正在寻找的那种证明。无论您向客户端发送什么,您的服务器总是可以发送真实网站所期望的准确值,然后立即切换到不同的代码。

可能有用的是审计员您发布了有关您和您的员工如何确保服务器真正运行您的代码而不是其他东西的详细程序。这些程序包括您的密码策略、维护规则、代码审查、托管服务物理安全、员工犯罪记录和债务状况筛查,以及无数其他要点。然后你付钱让审计公司派人检查你的程序,看看你是否遵守它们;他们最终写了一份报告,告诉您您确实遵循了所有程序。这并不能证明网站确实在运行它应该运行的代码,但它表明您至少为实现该目标付出了巨大的努力。

正式地,这个过程被称为WebTrust它是昂贵的。

最简洁的答案是不。

在某些时候总会有一些漏洞,但是如果您的服务是安全的,并且如果您可以强制客户端在某些情况下运行,则可以将风险降到最低。总是有风险,了解它们,因为你不知道会伤害你。