有一家银行通过其网站提供一些服务。开发人员考虑了任何作为整个系统的有效用户登录的人，他们使用URL来识别账号，因此只需更改URL上的ID，就可以查看其他账户的余额。

对于认为身份验证和授权是一回事的web开发人员来说，这是非常糟糕的。

此外，银行不通过其网站转账也很好，否则有些人会很富有;-)

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

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

我曾经在一个名为ROL的本地互联网门户网站上发现了一个漏洞。RO(罗马尼亚在线-当时由PCNET拥有)。他们有一个免费的网络邮件系统。我想要一个特定的用户名(很容易猜到是哪个)，但它已经被占用了。

出于好奇，我进入了“忘记密码”页面，输入了我想要的(但已被占用的)用户名。然后，在提交时，我看到了一个空白的安全问题。

哇……让我们看看他们是不是很差劲。我确保答案文本框为空，然后提交

“恭喜你，输入你的新密码”。

我输入了密码，劫持了账户。

可能发生在他们的…PHP脚本是他们比较从数据库(在答案-当然他们保持在明文)的空字符串提交我。让它们“相等”引导我进入下一步，重置密码。

是的,站不住脚的。

我在浏览一个购物网站，当我输入我的电子邮件地址时，我注意到地址输入页面的URL只有“?nOrderID=301”。

下车。我把数字改成99，你猜怎么着?我得到了一位住在本德的女士的名字，地址和电话号码。

几周前我确实给网站管理员发过邮件，他听起来不太高兴，但这个问题仍然没有解决……

有一段时间，该公司的整个员工信息列表(从地址到社会安全号到工资的所有信息)都存储在密码保护的Access数据库中。

使用您最喜欢的搜索引擎，查找如何恢复访问数据库的密码。是的。

拖拽到这里，你就会得到密码。字典中五个字母组成的单词。

去年，我发现我所在的公司用来处理支票/报表的网站充满了SQL注入漏洞。

不用说，他们很快就把洞补好了。

最不可原谅的安全漏洞，不幸的是，一个非常常见和容易找到的漏洞，是谷歌黑客。举个例子:

http://www.google.com/search?q=inurl%3Aselect+inurl%3A%2520+inurl%3Afrom+inurl%3Awhere

令人惊讶的是，互联网上有多少页面，特别是政府网站，通过查询字符串传递SQL查询。这是最糟糕的SQL注入形式，查找易受攻击的站点毫不费力。

经过一些小的调整，我已经能够找到未受保护的phpMyAdmin安装，未受保护的MySQL安装，查询包含用户名和密码的字符串，等等。