我被告知，我们总机部门的哔哔系统有一个可以用来发送消息的web前端，尽管它很丑，而且不太友好，所以我想看看我们是否可以在我们的内部网主站上使用一个表单，并通过我们的服务器将值提交给他们。

使用User和Admin角色访问系统有一个简单的用户名/密码表单，因此我查看了一下如何实现处理安全性。我发现存储了以下两个cookie:

Username: [username I had used]
Admin: False

为了确保它像我想象的那样糟糕，我打开Firefox，给它url，创建2个cookie，我的用户名和管理员:真，瞧，我有管理员权限。为了验证它，我创建了一个新用户，没有任何问题。更糟糕的是，在本地使用用户名意味着日志将显示我的操作来自任何我想要给它的人。

通过不公开来实现安全是行不通的，但当你把人们需要的一切都放在银盘上时，它就不那么管用了。

几年前，一位朋友给了我一把他发现的旧斧头，希望我告诉他这是一件古老的人工制品。所以，我在谷歌上搜索了一些可能有助于识别的网站，得到了一个链接到英国中部某处的博物馆网站。

只不过它把我放到的那个页面给了我整个网站的完全管理员权限。作为一个负责任的人，我更改了账户所有者的名字，这样他们就知道我不是在胡说八道，并给他们发了一封电子邮件，建议他们在更恶毒的人发现之前，把让我进入的漏洞堵上。

不用说，我收到了网站所有者的一封非常感谢的电子邮件，开发人员向他保证，错误已经被发现并修复了。尽管你不得不怀疑一个如此粗心大意的人的能力。

About 3 years ago I built a site for a somewhat large non-profit organization in our state. When it came time to deploy the application to their web host server, I noticed an odd file named "cc.txt" or something obvious like that in their public site. It was under their web root, was getting served, and was a csv file of all their donor's names, addresses, credit card numbers, expiration dates, and CVV/CVC codes. I cannot count the number of times I brought the issue up - first to my boss, then our company accountant, the client's IT director, finally the client's President. That was 3 years ago. The file is still being served, it can even be googled. And it's been updated. I tend not to respond to their donation solicitations when I get them.

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

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

不是最糟糕的，但很好笑的一个是Android操作系统重启的bug。当用户使用G1手机时，他们可以在手机的任何地方输入“重启”(比如:短信或电子邮件)，手机就会重新启动。

在登录时，有一个隐藏的字段，让“网站管理员”选择成功和失败时要包含的文件。

是的，/etc/password工作了。

或者在“log”目录中，有order-xxx。order-xxx.txt包含卡号，包括检查号和验证日期。