你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。

不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。


当前回答

我投票给Ken Thompson的UNIX“后门”。

这里有一个链接,有人可以从中了解更多信息: 汤普森木马编译器

我之所以认为这是最糟糕的,是因为在那个时候,法官们认为,在这种事情上取得进展的最好方法是公开讨论。

这一切只是教会了一群脚本小子一个新的非常强大的技巧。

其他回答

我的目标是我曾经的客户。我无法登录,所以我打了客服电话。他们只问了我的用户名,没有问任何安全问题,也没有试图验证我的身份。然后,他们没有将密码重置发送到他们存档的电子邮件地址,而是问我该发送到哪个电子邮件地址。我给了他们一个不同于我文件上的地址,并重新设置了密码。

所以本质上,黑客只需要我的用户名,他就可以访问我的账户。这是一家至少90%的美国人都听说过的大银行。这件事发生在大约两年前。我不知道这是一个缺乏训练的客户服务代表还是这是标准程序。

这里可能有一点轶事故事(但因为这是我发现的最糟糕的安全漏洞)…

有一家公司向许多公司/组织(不幸的是包括我们)出售定制CMS(用于网站)。他们使用了相当多的(主要是“LGPL”)他们自己没有制作的组件。很多客户(包括政府)。

正确处理了访问网站不同部分(以及CMS管理系统)的身份验证。 他们在CMS中使用了FCKEditor实例(允许非html保存的用户编辑网页)。 他们还使用FCKEditor的“上传连接器”脚本,允许用户添加文档,图像等。到现场。这个脚本的url是硬编码在一个公开可见的javascript包含中。 他们无法对带有上传脚本的url进行身份验证。

结果:在他们建立的每个网站上,用户都可以(不需要输入任何凭据)修改/删除/更改/上传网站上的每一个文档/文件和/或图像。

我们一发现这个漏洞就立即报告了,所以它可能不会导致直接损害(但很容易)。

我认为超级用户访问的空白用户名/密码字段是迄今为止最糟糕的。但我亲眼看到的是

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

太糟糕了,一个操作员就有这么大的不同。

2007年,一家相当大的机构的国防部网站出现了错误配置,导致IIS web服务器提供原始代码,主页中有硬编码的用户名/密码和数据库服务器信息。幸运的是,它很快就被抓住了,但我确实目睹了它,这非常令人震惊。不用说,他们的网站被网络工程师关闭了,直到开发人员修复了糟糕的代码。

严格地说,这不是一个安全漏洞,更多的是一个“功能”,许多新手服务器管理员当时并不知道/关心。

在1999-2001年间,我玩Frontpage玩得很开心,解锁了安装在公共网站上的Frontpage服务器扩展。

当你安装了Frontpage后,你会在ie浏览器中看到这个很好用的“编辑Frontpage”按钮。

当访问一个网站,例如www.foo.com,如果你点击“编辑在Frontpage”按钮在Internet Explorer和服务器管理员没有正确地完成他们的工作,然后Frontpage愉快地打开虚拟目录的完整目录结构,并允许你阅读/编辑内容。

从一个人的乐队到更大的公共组织,这种方法在许多网站上都有效。

当我发现一个开放的服务器时,我总是给“网站管理员”发一封电子邮件,有一次我从一家在线零售商那里得到了一张50英镑的礼券,因为我提醒了他们这一点。

真是令人震惊。

免责声明-我需要指出的是,Frontpage是在标准构建PC上,我是在那些天,不是我自己的选择!