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

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


当前回答

我工作的公司有很多安全错误……下面是一些比较糟糕的例子:

所有的前雇员仍然拥有所有东西的活跃账户,即使是那些被解雇或关系不好的人 我们开发的每个站点(200多个)都有相同的管理员用户名和密码,所有在这里工作的员工都知道

史诗般的失败。

其他回答

对我来说,最糟糕的,最可怕的,最危险的,犯罪的疏忽,但在彻底破坏整个系统的安全方面,奇怪的优雅总是来自the Daily WTF:

客户端PHP

function saveform()
{
  var firstName = escapeSql(mainForm.elements.txtFirstName.value);
  var lastName = escapeSql(mainForm.elements.txtLastName.value);
  /* ... */
  var offerCode = escapeSql(mainForm.elements.txtOfferCode.value);

  var code =
  '  $cn = mssql_connect($DB_SERVER, $DB_USERNAME, $DB_PASSWORD)           ' +
  '          or die("ERROR: Cannot Connect to $DB_SERVER");                ' +
  '  $db = mssql_select_db($DB_NAME, $cn);                                 ' +
  '                                                                        ' +
  '  if (mssql_query("SELECT 1 FROM APPS WHERE SSN=\''+ssn+'\'", $cn)) ' +
  '  { $ins = false; }                                                     ' +
  '  else                                                                  ' +
  '  { $ins = true; }                                                      ' +
  '                                                                        ' +
  '  if ($ins) {                                                           ' +
  '    $sql = "INSERT INTO APPS (FIRSTNM, LASTNM, ..., OFFERCD) VALUES ("; ' +
  '    $sql+= "\''+firstName+'\',";                                        ' +
  '    $sql+= "\''+lastName+'\',";                                         ' +
  '    $sql+= "\''+offerCode+'\')";                                        ' +
  '                                                                        ' +
  '  /* ... */                                                             ' +
  '                                                                        ' +
  '  mssql_query($sql, $cn);                                               ' +
  '  mssql_close($cn);                                                     ';

  execPhp(code);
}

就盯着它看一分钟。想想你所能做的一切。女士们先生们,这是洛夫克拉夫特的杰作。

我个人发现的最糟糕的情况是,在一所大学,所有系统(包括教授办公室)都使用运行X的机器。一台服务器托管了所有这些X会话……

有趣的是,您可以启动一个新的X应用程序(时钟是最受欢迎的,但任何X应用程序都可以工作),并选择显示它的终端。有了一个快速的脚本,你就可以在校园里每个实验室/办公室的每台电脑上启动它……

当然,真正暴露这个安全漏洞的应用程序是一个虚假的shell登录,其中的输入被记录到一个文件中。

它运行了一周,获得了数百名学生和教授的用户名和密码,并产生了一对非常不高兴的管理员。

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

直到有一天你醒来,看到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中造成并随后修复了更多的安全漏洞,但它们都没有得到应有的宣传。

最大的安全漏洞是web开发人员在设计开放密码字段的注册表单时。密码字段显示您键入的内容,而不是将其清空。这样,当你在公共计算机上注册表单时,就可以看到你在密码字段中输入了什么。许多网站确实有这样的注册表单。

我相信很少有低安全性的网站,用户的密码和登录信息可以很容易地被管理员访问。

一位同学曾经不小心把密码发到了推特上……那是个很严重的安全漏洞。