当你丢失了密码和找回表格时，询问用户名和你的电子邮件。并且不验证电子邮件并将密码发送到指定的电子邮件。

刚)一/总动员:

这是在一个本地电视付费/订阅的网站上。很容易找到用户名，很多人使用名字。今天这个电视频道已经破产了(因为其他原因，比如缺乏专业精神)。

当我13岁的时候，我的学校为学生开设了一个社交网络。不幸的是，我发现了一个安全漏洞，可以将URI更改为另一个用户id，如“?”userID=123”，并为该用户登录。显然，我告诉了我的朋友们，最后学校的社交网络充满了色情。

不过我不推荐。

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

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

不是技术上的安全漏洞，但仍然是一个安全漏洞:

我的银行卡最近被自动取款机吃了，我花了几个星期才把它拿回来。当它最终到达银行时，银行的一位女士打电话给我，问我是想自己取卡还是让他们邮寄给我。她还告诉我，如果他们要寄给我，他们会关闭它，直到我打电话给他们确认它安全抵达我家。

我收到了这张卡，并附上了一封简短的信，上面有确切的联系方式，其中包括一张便条，说我需要打电话重新启用这张卡。我只是打电话给他们，给了他们我的名字和账号，这两个都印在卡上，他们重新启用了卡。

基本上，如果有人抢了那封信，他们就会有信用卡和银行号码，以及所有需要的信息，让银行相信实际上是我打来的。所以那里的安全系统不太好。

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

想到这一点，我所见过的最糟糕的安全漏洞是当管理电子门锁的人说“你是什么意思，锁不知道公共假日”?

是的，每个周一到周五都是公共假日，因为门系统已经安装好了，我看到前门在08:00-17:30没有锁。