简单地说

exec unchecked_parameter_from_the_web

在Python中解析用户给出的字典字面量。那真的很可怕。

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

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

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

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

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

最大的安全漏洞是web开发人员在设计开放密码字段的注册表单时。密码字段显示您键入的内容，而不是将其清空。这样，当你在公共计算机上注册表单时，就可以看到你在密码字段中输入了什么。许多网站确实有这样的注册表单。

我相信很少有低安全性的网站，用户的密码和登录信息可以很容易地被管理员访问。

在我以前的学校，他们把用户密码以明文形式存储在cookie中。

这本身就很可怕，但更糟糕的是，他们把它们储存在饼干里供*.大学。当然，现在所有学生和员工的页面都在university.edu.au/~user这样的网站上。

<?php

var_dump($_COOKIE); // oops.

2007年，一家相当大的机构的国防部网站出现了错误配置，导致IIS web服务器提供原始代码，主页中有硬编码的用户名/密码和数据库服务器信息。幸运的是，它很快就被抓住了，但我确实目睹了它，这非常令人震惊。不用说，他们的网站被网络工程师关闭了，直到开发人员修复了糟糕的代码。

Right at the start of the .com era, I was working for a large retailer overseas. We watched with great interest as our competitors launched an online store months before us. Of course, we went to try it out... and quickly realized that our shopping carts were getting mixed up. After playing with the query string a bit, we realized we could hijack each other's sessions. With good timing, you could change the delivery address but leave the payment method alone... all that after having filled the cart with your favorite items.