在一所不知名的大学，他们所有的动作查询都是通过URL传递的，而不是通过表单发布的。

这个东西一直在工作，直到谷歌Bot出现，运行了他们所有的url并删除了他们的数据库。

默认登录凭据，特别是当是admin/root和密码时。

不过这还不是我见过的最严重的安全漏洞。但这至少是我自己发现的最糟糕的情况:

一个非常成功的在线有声读物商店在成功认证后使用cookie存储当前用户的身份信息。但你可以很容易地在cookie中更改用户ID，并访问其他账户并在这些账户上购物。

我工作的公司有很多安全错误……下面是一些比较糟糕的例子:

所有的前雇员仍然拥有所有东西的活跃账户，即使是那些被解雇或关系不好的人 我们开发的每个站点(200多个)都有相同的管理员用户名和密码，所有在这里工作的员工都知道

史诗般的失败。

这里有一个我不常看到的例子。这是一个非常有效的安全漏洞，困扰着大多数登录表单。我大约在十年前发现了它。

我在多伦多大学学习，那里有一个叫做ROSI的系统，允许学生管理他们的费用和课程注册。他们还在总会议区设置了两个公共终端，只能显示ROSI网站，学生可以输入他们的学生证和密码登录和管理他们的物品。

但是，在用户注销后，您可以在终端上按浏览器的alt-left键返回登录表单，然后按alt-right键前进一键，然后单击刷新。在这一点上，浏览器会要求你确认重新发布表单数据，如果你点击是，它会重新发布以前的用户登录/通过和登录你。

大多数登录表单仍然容易受到这类攻击。解决方案是post/redirect/get或使用nonce键。

我给我的大学管理员发了很多次邮件，但我认为他们至少在我毕业离开之前都没有解决这个问题。这大约是在2002年。

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

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