你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。

不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。


当前回答

我曾在一家销售点公司工作。他们的软件 很多披萨店都用过。

由客户决定是否更改默认密码。 默认信息在用户手册和手册中打印 这样的。:)

几个在披萨店工作的孩子 我猜他们没有更改根密码(Unix/Linux 基于系统)。然后他们去买他和他的 朋友免费送披萨到他家近一个月 在披萨店注意到之前一年。这让我发笑 每次我想到那份工作。:)

其他回答

我记得申请大学的通用应用程序网站有这个“安全”功能,它宣布将在一定时间后注销你。但是,他们使用了一个警告框,如果你没有真正回应,就会暂停倒计时,使你的会话无限期。

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

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

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

作为一个以应用程序安全顾问为生的人,有很多常见的问题让你通过一些东西来管理网站。但真正酷的是你可以买到价值一百万美元的袜子。

这是我的一个朋友的工作,但它的真实情况是,某个现在非常流行的在线图书(和其他所有东西)商店的商品价格被存储在HTML本身作为一个隐藏字段。在早期,这个漏洞困扰了许多在线商店,他们刚刚开始了解网络。几乎没有安全意识,谁会下载HTML,编辑隐藏字段,然后重新提交订单呢?

当然,我们把价格改为0,并订购了100万双袜子。你也可以改变价格为负,但这样做使他们的后端计费软件缓冲区溢出结束交易的一部分。

如果我可以选择另一个,那就是web应用程序中的路径规范化问题。能够执行foo.com?file=../../../ etc/passwd真是太棒了

在一些Unix机器(当然是所有的SunOS)上,您可以将setuid shell脚本链接到一个名为“-i”的文件。 shell脚本将文件名解释为它的第一个参数,并运行"sh -i" =一个交互式shell,并获得setuid文件所有者的许可。

因为大多数setuid shell脚本都是以根用户身份运行的,以便允许您执行一些需要根用户权限的操作,比如弹出CD或加载磁带。这意味着在20世纪90年代,在大多数大学的Unix机器上获得管理是很简单的。

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