你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
当前回答
"select * from LoginMaster where UserId='" + txtUserId.Text + "'
and Password='" + txtPassword.Text + "';"
我曾在一个经营直销业务的生产网站上看到过这种情况。上面的Sql语句非常非常容易受到Sql注入的攻击。
我还将在这里列出HACME银行。根据网站Hacme银行是:
Hacme Bank™ is designed to teach application developers, programmers, architects and security professionals how to create secure software. Hacme Bank simulates a "real-world" web services-enabled online banking application, which was built with a number of known and common vulnerabilities. This allows users to attempt real exploits against a web application and thus learn the specifics of the issue and how best to fix it. The web services exposed by Hacme Bank are used by our other testing applications including Hacme Books and Hacme Travel.
其他回答
I was going to earn my credit with the supervisor for my quite advanced graphics program at a SunOS / Solaris with instant messaging enabled where with zephyr.vars or whatever it was called you could make an image appear on your listed friend's screen like if you alowed me I could just send you an image that appeared on your display. While I was demoing the program I had written so that the supervisor could give me credit for it, one of my friends sitting close or in the next room made the photo big-mama.xxx appear on my screen. There was never any discussion or penalty because of the incident and I got credit for the project that for ½ second seemed like it was programmed to display big-mama.xxx instead of solving the problem. (Earlier) I updated perl scripts and waited for sysadmin to reflect the changes to ouside the FW. Then the database was gone and it was not a bug it was a feature since the data was stored with the source and therefore updating the source blanked the persistence.
物理访问或模拟登录提示或登录屏幕是另外两种困难的情况,不需要过多的算法技术,很容易理解物理访问提供了许多可能性,模拟登录提示是您可以在许多不同类型的计算机和环境上进行的事情。
我最后工作的公司的FTP用户名和密码与他们的域名相同。他们不太在意反复警告。
不用说,网站没过多久就倒闭了。没有在线备份,所以他们不得不重建整个系统。但这并没有结束。这次事件后的新安全密码是一样的…加上123。
http://www.metasploit.com/users/hdm/tools/debian-openssl/
这是我在微软早期的真实故事。
直到有一天你醒来,看到ZDNet.com上的头条是“在'Blah'中发现了有史以来最严重的ie安全漏洞”,你才知道什么是恐惧,而'Blah'是你六个月前自己写的代码。
在开始工作后,我立即检查了更改日志,发现另一个团队中的某人——我们信任的对产品进行更改的人——签出了我的代码,毫无理由地更改了一堆安全注册表项设置,重新签入,并且从未得到代码审查或告诉任何人。直到今天,我还不知道他到底在做什么;此后不久,他就离开了公司。(自愿的。)
(更新:对评论中提出的问题进行了一些回应:
首先,请注意,我选择采取宽容的立场,即安全密钥的更改是无意的,是基于粗心或不熟悉,而不是恶意的。我没有这样或那样的证据,我相信把错误归咎于人的易犯错误是明智的。
其次,我们现在的签到系统比12年前强大得多。例如,如果签入系统不将更改列表通过电子邮件发送给相关方,现在就不可能签入代码。特别是,在开发周期后期所做的更改有很多“流程”,这确保了所做的更改是正确的,以确保产品的稳定性和安全性。)
Anyway, the bug was that an object which was NOT safe to be used from Internet Explorer had been accidentally released as being marked "safe for scripting". The object was capable of writing binary files -- OLE Automation type libraries, in fact -- to arbitrary disk locations. This meant that an attacker could craft a type library that contained certain strings of hostile code, save it to a path that was a known executable location, give it the extension of something that would cause a script to run, and hope that somehow the user would accidentally run the code. I do not know of any successful "real world" attacks that used this vulnerability, but it was possible to craft a working exploit with it.
让我告诉你,我们很快就为这款游戏发布了补丁。
我在JScript中造成并随后修复了更多的安全漏洞,但它们都没有得到应有的宣传。
我投票给Ken Thompson的UNIX“后门”。
这里有一个链接,有人可以从中了解更多信息: 汤普森木马编译器
我之所以认为这是最糟糕的,是因为在那个时候,法官们认为,在这种事情上取得进展的最好方法是公开讨论。
这一切只是教会了一群脚本小子一个新的非常强大的技巧。