在我工作的一个网站上，他们使用用户名和密码作为组合主键。用户名自动是您的姓，不需要唯一。

这就只剩下一件独一无二的事情了…

我的任务是发现一个用于报告的ODBC DSN，其中密码与用户匹配，并且用户属于数据库服务器管理组。

因此，任何具有此ODBC DSN的PC都可以使用任何ODBC兼容工具通过报表用户读取/更改所有数据(甚至更糟)。不需要授权，而且身份验证非常弱。

我在一家公立医院工作，这个软件几乎安装在该州每家政府医院的每一台电脑上，数据库服务器包含各种敏感的医疗数据(完整的患者详细信息、实验室测试结果等)。

最糟糕的是，我们悄无声息地报告了安全漏洞，然后正式报告，但在我继续在那里工作的2年里，它仍然没有修复，那已经是5年前的事了。

IIS上的Web应用程序，没有文件上传过滤器。所以你可以上传exe，并做smf乐趣;)

我继承了一个客户项目来照看:一个ASP。网项目 (构建于1.1)，其中50%是编译DLL(没有编译DLL) 源代码)和50%的JIT编译后代码。

整个网站应该只对会员开放——除了 原来的开发人员已经建立了一个后门:只需提交 用空白的用户名和密码登录表单，你就会 找到自己作为一个秘密的超级管理员登录:做 什么都看，什么都看。

您猜对了:所有的身份验证代码都被隐藏了 在预编译的DLL中。最糟糕的是当我 被告知“它不在bug列表中，那么客户端呢? 不会付钱，所以离开它”。我照做了，现在还在直播 今天。

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.

我的朋友曾经用PHP编写了一个论坛脚本。密码保存为一个名为pass.txt的纯文本文件。当然，每个人都可以访问那个文件。