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

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


当前回答

我的朋友曾经用PHP编写了一个论坛脚本。密码保存为一个名为pass.txt的纯文本文件。当然,每个人都可以访问那个文件。

其他回答

不是最坏的,但也足以造成一些真正的损害。你会惊讶于这一点被忽视的频率有多高。特别是当人们使用这些流行的框架时,

yourwebapp.com/items/edit.php?id=4
yourwebapp.com/items/delete.php?id=4

不确定项的所有者是请求页面的人。 也就是说,你可以登录你的账户,然后在整个应用程序中编辑或删除任何人的项目。

一个简单的检查可以防止很多损坏。

$item = // find your item by the $_GET[ 'id' ];

if( $_SESSION[ 'user_id' ] != $item[ 'user_id' ] ){
  // kick em out they dont belong...
}

我们有一个旧的计算机集群,在我工作的一个实验室里没有运行。几个本科生认为,让它运行起来会很有趣,这样他们就可以学习一点并行计算了。他们让它运行起来,结果证明它非常有用。

One day I came in and was checking out the stats...It was running at 100%. Now this was a 24 node cluster and there were only 3 of us that ever used it so it was a little strange that it was running at this load. I started playing with it, trying to figure out what was loading it...turned out someone had gained access and was using it as their own little porn server and spammer. I asked the undergrads what kind of security they put on it, they looked at me and said "Security? We didn't think it would need any."

我给它加了个密码,就这样。把它用作色情服务器的人原来是一个本科生的朋友。

我将分享一个我创造的。种。

多年、多年、多年以前,我工作的公司需要在他们的ASP网站上建立索引。所以我去设置索引服务器,排除了一些管理目录,一切都很好。

然而,我不知道有人给了一个销售人员ftp访问网络服务器,这样他就可以在家工作,这是拨号的日子,这是他交换文件的最简单的方式....他开始上传东西,包括详细说明我们服务....标记的文档当人们搜索“成本”时,索引服务器就会索引并开始提供服务。

记住,孩子们,白名单不是黑名单。

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

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

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

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

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

这是我在微软早期的真实故事。

直到有一天你醒来,看到ZDNet.com上的头条是“在'Blah'中发现了有史以来最严重的ie安全漏洞”,你才知道什么是恐惧,而'Blah'是你六个月前自己写的代码。

在开始工作后,我立即检查了更改日志,发现另一个团队中的某人——我们信任的对产品进行更改的人——签出了我的代码,毫无理由地更改了一堆安全注册表项设置,重新签入,并且从未得到代码审查或告诉任何人。直到今天,我还不知道他到底在做什么;此后不久,他就离开了公司。(自愿的。)

(更新:对评论中提出的问题进行了一些回应:

首先,请注意,我选择采取宽容的立场,即安全密钥的更改是无意的,是基于粗心或不熟悉,而不是恶意的。我没有这样或那样的证据,我相信把错误归咎于人的易犯错误是明智的。

其次,我们现在的签到系统比12年前强大得多。例如,如果签入系统不将更改列表通过电子邮件发送给相关方,现在就不可能签入代码。特别是,在开发周期后期所做的更改有很多“流程”,这确保了所做的更改是正确的,以确保产品的稳定性和安全性。)

Anyway, the bug was that an object which was NOT safe to be used from Internet Explorer had been accidentally released as being marked "safe for scripting". The object was capable of writing binary files -- OLE Automation type libraries, in fact -- to arbitrary disk locations. This meant that an attacker could craft a type library that contained certain strings of hostile code, save it to a path that was a known executable location, give it the extension of something that would cause a script to run, and hope that somehow the user would accidentally run the code. I do not know of any successful "real world" attacks that used this vulnerability, but it was possible to craft a working exploit with it.

让我告诉你,我们很快就为这款游戏发布了补丁。

我在JScript中造成并随后修复了更多的安全漏洞,但它们都没有得到应有的宣传。