你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
当前回答
一位同学曾经不小心把密码发到了推特上……那是个很严重的安全漏洞。
其他回答
我的第一份工作是在IT安全部门实习。我的任务是自动化对不同用户帐户的网络和应用程序访问,因为每个用户都转移到不同的部门/角色。也就是说,我可以使用一些基本的工具,比如查询分析器,以及一些数据库,但其他的就不多了。该公司通常会把所有东西都锁起来,所以总是有重置和授予的权限。
在这份工作中,所有的兼职人员都被要求使用一个小的VB胖客户端应用程序来跟踪工作时间,在一周结束时,一个按钮可以显示登录的用户一周工作了多少小时,以及他们这一周将获得多少报酬。
出于纯粹的无聊,有一天我偶然发现了小时间跟踪应用程序驻留在网络上的目录,并注意到在该目录中除了EXE之外只有一个其他文件,一个settings.ini文件。
果不其然,打开文件后,连接字符串在明亮的闪光纯文本;用户、密码、数据库名、服务器等等。
在这一点上,我认为这不是真正的信息,但在启动查询分析器,并进入ini设置后,我进入了主生产数据库,其中有任何人都需要给自己加薪的每一块数据。对引导的完全读写权限。
最后,我向老板展示了一份关于谁赚多少钱的问题,他平静地让我把它转发给人力资源总监。
让我告诉你,在我的生活中,我从来没有收到过这么快的,亲自回复任何其他邮件的邮件。
第二天我开始工作,时间跟踪应用程序有一个更新,唉,没有更多的settings.ini文件。
一些验证码是这样的:
public bool charsEquals(char[] input, char[] txt)
{
for (int i = 0; i < Math.min(input.length; txt.length); ++i)
{
if (input[i] != txt[i]) return false;
}
return true;
}
像这样使用它:
if (charsEquals(inputPassword, requestedPassword))
看了YouTube上关于Tux和比尔·盖茨之战的搞笑视频后,我开始思考这个问题。当Tux没有密码进入微软大楼时。
我继承了一个客户项目来照看:一个ASP。网项目 (构建于1.1),其中50%是编译DLL(没有编译DLL) 源代码)和50%的JIT编译后代码。
整个网站应该只对会员开放——除了 原来的开发人员已经建立了一个后门:只需提交 用空白的用户名和密码登录表单,你就会 找到自己作为一个秘密的超级管理员登录:做 什么都看,什么都看。
您猜对了:所有的身份验证代码都被隐藏了 在预编译的DLL中。最糟糕的是当我 被告知“它不在bug列表中,那么客户端呢? 不会付钱,所以离开它”。我照做了,现在还在直播 今天。
中国的过滤软件——绿坝的官方网站将服务器mod_status信息公开供公众娱乐。
好奇的人:
http://www.lssw365.net/server-status
出于某种原因,你可能想在加载后不久按下停止按钮,否则它只是说由于某种原因连接重置…
我不知道这是不是最糟糕的,因为我见过一些非常糟糕的,但是:
几年前,我工作的地方引进了一个叫做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年代初,我相信他们已经解决了这个问题。嗯,非常确定。