一个让我害怕的安全漏洞是在我曾经维护的一个遗留应用程序中，其中有一个settings.ini文件，其中的数据库凭据是纯文本的，所有用户密码都以纯文本的形式存储在数据库中。

我见过的大多数安全漏洞都发生在我的高中和大学。

首先，我发现我可以通过(非常简单的)ping flood攻击来关闭学校的互联网。不仅仅是我高中的互联网，整个学校系统，包括大学的一部分。绝对没有速率限制。在我演示之后，他们最终把它修好了。(顺便说一句，我的第一份编程工作就是靠这种“宣传”获得的)

第二点，也是可能性更大的一点是:

Ok, so every computer in the school was connected to a domain and such. So, when you logged onto a computer, it would copy down a generic user directory(including application data, etc folders) and then proceed with the login. Some people had their own logins other than the generic "student" account for one reason or another. Well, while I was browsing the public server where everything was shared on, I found a /users directory. Upon looking at it I discovered froma generic student account I had read-write to every users directory, including teachers, administrator, and the generic student account.

为了愚人节，我计划写一个简单的批处理文件或小程序，弹出一些类似Class of 09 rocks的东西!登陆每个人只是为了演示它，但我退缩了。我也从来没有告诉过管理员，所以这个安全漏洞可能仍然存在。

整个经典ASP购物车“Comersus”。整个事情是意大利面条代码的混乱，所有的SQL语句都是成熟的SQL注入，因为没有做任何过滤。可悲的是，我不幸地处理了近两年的“申请”，这绝对是一场噩梦!

"select * from LoginMaster where UserId='" + txtUserId.Text + "' 

                           and Password='" + txtPassword.Text + "';"

我曾在一个经营直销业务的生产网站上看到过这种情况。上面的Sql语句非常非常容易受到Sql注入的攻击。

我还将在这里列出HACME银行。根据网站Hacme银行是:

Hacme Bank™ is designed to teach application developers, programmers, architects and security professionals how to create secure software. Hacme Bank simulates a "real-world" web services-enabled online banking application, which was built with a number of known and common vulnerabilities. This allows users to attempt real exploits against a web application and thus learn the specifics of the issue and how best to fix it. The web services exposed by Hacme Bank are used by our other testing applications including Hacme Books and Hacme Travel.

我个人发现的最糟糕的情况是，在一所大学，所有系统(包括教授办公室)都使用运行X的机器。一台服务器托管了所有这些X会话……

有趣的是，您可以启动一个新的X应用程序(时钟是最受欢迎的，但任何X应用程序都可以工作)，并选择显示它的终端。有了一个快速的脚本，你就可以在校园里每个实验室/办公室的每台电脑上启动它……

当然，真正暴露这个安全漏洞的应用程序是一个虚假的shell登录，其中的输入被记录到一个文件中。

它运行了一周，获得了数百名学生和教授的用户名和密码，并产生了一对非常不高兴的管理员。

当关键IT员工离开公司时，不更改管理密码。

有关安全漏洞(和其他计算机风险)的主列表，请访问http://catless.ncl.ac.uk/Risks