有许多网站使用代理文件来传送图像或其他文件。没有检查路径的有效性。

So.

getfile.php ?文件 =../../../../ 等/ passwd

or

Getfile.php ?file=../index.php(包含所有密码的纯文本)

令人惊讶的是，还有很多网站仍然存在这个缺陷。getfile.php只需要谷歌，你就可以轻松地打开盒子了。

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

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

因为用户名和密码是相同的，这是发生在生产网站而不是测试版本。

对我来说，情况并没有那么糟糕，因为数据并不是那么敏感:

我得到了一个Excel文件，里面满是要更新的宏，每个表都是锁定的，宏部分有密码保护。我拿到了密码，但我想我还是试着破解一下吧。

我找到了一个程序，可以在大约十分钟内完成，其中大部分时间可能只是下载时间。这个神奇的产品是什么，能如此快速和轻松地突破Excel安全?OpenOffice.Org。

我不确定Office 2007是否在这一点上有所改进，但让我感到害怕的是，许多非技术人员可能正在使用Excel来操作敏感信息，并认为它是安全的。然而，这些类型的人可能甚至不知道它提供的“安全”功能。

高中时，实验室正在运行windows的早期版本。政府在一项安全计划上花费了大量资金。

负责实验室的先生来找我，让我绕过系统看看它是否安全。“没关系，你不会有麻烦的。”

我重新启动，按f8，当它问我是否要加载安全程序时，按N，然后Y到其他所有东西上。

login.jsp?type=user&redirct=/home.jsp&userid=12345&username=username&password=mypassword

这发生在一个非常大的网站上。当我看到这个的时候，我惊呆了。