我曾经忘记删除“管理员登录页面”。该页面只是绕过LDAP登录并获得所有权限。它可以对客户的银行账户做任何事情。我非常非常担心。幸运的是，没有人知道URL。

几年前，一所学校托管了一个学习平台网站，可以上传。php文件到网站上，然后再执行，所以他们给了你整个网站的完全访问权限。还没有被其他学生发现，我认为这个错误仍然存在。

一个在线文档管理器怎么样，它允许设置你能记住的所有安全权限……

直到你进入下载页面……download.aspx吗?documentId = 12345

是的，documentId是数据库ID(自动递增)，您可以循环每个数字，任何人都可以获得所有公司文档。

当这个问题被提醒时，项目经理的回答是:好的，谢谢。但之前没有人注意到这一点，所以就让它保持现状吧。

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

直到有一天你醒来，看到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应用程序中的一个漏洞，即提供空用户名和密码将以管理员身份登录。

将用户名列表以明文形式发送给浏览器以供JavaScript自动补全，还可以通过使用唯一的用户id调整URL查询字符串来查看用户数据，这可以从自动补全功能中收集到。