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

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


当前回答

意外地将数据库根密码提交给源代码控制。这很糟糕,因为它是Sourceforge上的源代码控制。

不用说,密码很快就改了。

其他回答

旧的IBM System 36哑终端有一个开始录制宏的键盘组合。因此,当终端未登录时,您可以开始录制宏并将其留在该位置。下次有人登录时,击键将被记录在宏中,当记录最多允许的键时,记录将自动结束。稍后回来并重放宏以自动登录。

高中时,实验室正在运行windows的早期版本。政府在一项安全计划上花费了大量资金。

负责实验室的先生来找我,让我绕过系统看看它是否安全。“没关系,你不会有麻烦的。”

我重新启动,按f8,当它问我是否要加载安全程序时,按N,然后Y到其他所有东西上。

“网络编程安全101”风格的最大错误是招聘机构的搜索页面提供了“下一页”链接,这只是获取更多工作列表的SQL语句。您可以轻松地将此URL更改为任何其他SQL语句,包括“drop table X”。如果你这么做了,他们的整个网站都会完蛋。

我不知道这是不是最糟糕的,因为我见过一些非常糟糕的,但是:

几年前,我工作的地方引进了一个叫做FOCUS的系统。不知道它还在不在。它非常适合做报告,我们开发并教了大约一千两个非It人员如何生成他们自己的报告。非常方便。他们可以做基本的报告,一些人可以做中等难度的工作,IT可以帮助处理较难的工作。

所有用于报告的数据都被定期复制到FOCUS自己格式的影子数据库中。对于更敏感的数据,我们设置安全选项,加密数据。一切都很好。

So, one day my boss calls me in, and we've lost the password to one of the sensitive databases. It's going to be hard to reproduce the data in this case, so he asks me to see if I can break the security. I had no experience as a hacker, so it took me about 5 or 6 hours to hand him the password. I started by creating some test files, and encrypting them with different passwords. I found that changing one character in the password would change two bytes in the encrypted file, specifically, the high nybble of one byte, and the low nybble of another byte. Hmmmm, says I. Sure enough, they stored the password somewhere in the first 80 bytes of the encrypted, but obfuscated the password by splitting the bytes into nybbles, and storing them in predictable places.

不久之后,我们就编写了一个REXX脚本,该脚本在VM/CMS系统下运行,可以告诉我们任何加密数据库的密码。

那是很久以前的事了——在90年代初,我相信他们已经解决了这个问题。嗯,非常确定。

我的一家公用事业公司在他们的信用卡表单中没有使用自动完成="off"。

当然,他们不会存储你的信用卡信息(一件好事),但想象一下当我支付第二个月的账单时,我有多害怕,我的浏览器竟然为我填写整个信用卡号码……