你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
当前回答
事实上,只要使用文件/进程十六进制编辑器,就可以在大多数未加密的应用程序或文件上绕过安全性或预期功能。当然,在大多数游戏(在线或离线)中给自己无限的金币或上帝模式是很棒的,但它也很棒,只是抓取或编辑你想要的值,包括密码。事实上,有时候你只需要记事本。幸运的是,记事本不在DMCA联邦控制的计算机应用程序名单上…然而。
编辑:我指的是利用“皇帝的新衣”场景,用最简单的工具识别安全缺陷。这种场景在任何语言或平台的编程或消费者社区中都很常见,甚至可以成为通用标准。
其他回答
http://www.metasploit.com/users/hdm/tools/debian-openssl/
意外地将数据库根密码提交给源代码控制。这很糟糕,因为它是Sourceforge上的源代码控制。
不用说,密码很快就改了。
我不知道这是不是最糟糕的,因为我见过一些非常糟糕的,但是:
几年前,我工作的地方引进了一个叫做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年代初,我相信他们已经解决了这个问题。嗯,非常确定。
简单地说
exec unchecked_parameter_from_the_web
在Python中解析用户给出的字典字面量。那真的很可怕。
我将分享一个我创造的。种。
多年、多年、多年以前,我工作的公司需要在他们的ASP网站上建立索引。所以我去设置索引服务器,排除了一些管理目录,一切都很好。
然而,我不知道有人给了一个销售人员ftp访问网络服务器,这样他就可以在家工作,这是拨号的日子,这是他交换文件的最简单的方式....他开始上传东西,包括详细说明我们服务....标记的文档当人们搜索“成本”时,索引服务器就会索引并开始提供服务。
记住,孩子们,白名单不是黑名单。