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

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

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

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

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

我曾经做过一份工作，其中有一个用Java代码编写的安全层，用于检查用户是否有权编辑DB表列。这是函数的样子:

public boolean canEdit(User user, DBColumn column) {
    if(true) {
        return true;
    } else {
        return false;
    }
}

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

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

Username: [username I had used]
Admin: False

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

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

我认为超级用户访问的空白用户名/密码字段是迄今为止最糟糕的。但我亲眼看到的是

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

太糟糕了，一个操作员就有这么大的不同。

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

人们把密码贴在公共网站上……