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

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

我的第一份工作是在IT安全部门实习。我的任务是自动化对不同用户帐户的网络和应用程序访问，因为每个用户都转移到不同的部门/角色。也就是说，我可以使用一些基本的工具，比如查询分析器，以及一些数据库，但其他的就不多了。该公司通常会把所有东西都锁起来，所以总是有重置和授予的权限。

在这份工作中，所有的兼职人员都被要求使用一个小的VB胖客户端应用程序来跟踪工作时间，在一周结束时，一个按钮可以显示登录的用户一周工作了多少小时，以及他们这一周将获得多少报酬。

出于纯粹的无聊，有一天我偶然发现了小时间跟踪应用程序驻留在网络上的目录，并注意到在该目录中除了EXE之外只有一个其他文件，一个settings.ini文件。

果不其然，打开文件后，连接字符串在明亮的闪光纯文本;用户、密码、数据库名、服务器等等。

在这一点上，我认为这不是真正的信息，但在启动查询分析器，并进入ini设置后，我进入了主生产数据库，其中有任何人都需要给自己加薪的每一块数据。对引导的完全读写权限。

最后，我向老板展示了一份关于谁赚多少钱的问题，他平静地让我把它转发给人力资源总监。

让我告诉你，在我的生活中，我从来没有收到过这么快的，亲自回复任何其他邮件的邮件。

第二天我开始工作，时间跟踪应用程序有一个更新，唉，没有更多的settings.ini文件。

if( $session['role'] = "admin" ) //grant admin rights

只要少一个字符(“=”而不是“==”)，就可以向登录的任何人授予管理权限。你是有罪的。

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

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

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

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

1-800 dominos will give unlisted address's related to any target phone number. When prompted if you are calling about the phone number you called from select no. The system will prompt you for a new phone number, the system will then read back to you the name and address that's associated to this phone number. Enter in your target's phone number and you now have their name and address. This is pretty common with automated ordering systems and if dominos has fixed this there are literally hundreds more.

http://apache.org/.svn/entries