有一家银行通过其网站提供一些服务。开发人员考虑了任何作为整个系统的有效用户登录的人，他们使用URL来识别账号，因此只需更改URL上的ID，就可以查看其他账户的余额。

对于认为身份验证和授权是一回事的web开发人员来说，这是非常糟糕的。

此外，银行不通过其网站转账也很好，否则有些人会很富有;-)

这里可能有一点轶事故事(但因为这是我发现的最糟糕的安全漏洞)…

有一家公司向许多公司/组织(不幸的是包括我们)出售定制CMS(用于网站)。他们使用了相当多的(主要是“LGPL”)他们自己没有制作的组件。很多客户(包括政府)。

正确处理了访问网站不同部分(以及CMS管理系统)的身份验证。 他们在CMS中使用了FCKEditor实例(允许非html保存的用户编辑网页)。 他们还使用FCKEditor的“上传连接器”脚本，允许用户添加文档，图像等。到现场。这个脚本的url是硬编码在一个公开可见的javascript包含中。 他们无法对带有上传脚本的url进行身份验证。

结果:在他们建立的每个网站上，用户都可以(不需要输入任何凭据)修改/删除/更改/上传网站上的每一个文档/文件和/或图像。

我们一发现这个漏洞就立即报告了，所以它可能不会导致直接损害(但很容易)。

login.jsp?type=user&redirct=/home.jsp&userid=12345&username=username&password=mypassword

这发生在一个非常大的网站上。当我看到这个的时候，我惊呆了。

不是最坏的，但也足以造成一些真正的损害。你会惊讶于这一点被忽视的频率有多高。特别是当人们使用这些流行的框架时，

yourwebapp.com/items/edit.php?id=4
yourwebapp.com/items/delete.php?id=4

不确定项的所有者是请求页面的人。 也就是说，你可以登录你的账户，然后在整个应用程序中编辑或删除任何人的项目。

一个简单的检查可以防止很多损坏。

$item = // find your item by the $_GET[ 'id' ];

if( $_SESSION[ 'user_id' ] != $item[ 'user_id' ] ){
  // kick em out they dont belong...
}

因为用户名和密码是相同的，这是发生在生产网站而不是测试版本。

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

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