你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
你见过的最糟糕的安全漏洞是什么?为了保护罪犯,限制细节可能是个好主意。
不管怎样,这里有一个关于如果你发现了安全漏洞该怎么办的问题,还有一个关于如果公司(似乎)没有回应该怎么办的问题。
当前回答
Right at the start of the .com era, I was working for a large retailer overseas. We watched with great interest as our competitors launched an online store months before us. Of course, we went to try it out... and quickly realized that our shopping carts were getting mixed up. After playing with the query string a bit, we realized we could hijack each other's sessions. With good timing, you could change the delivery address but leave the payment method alone... all that after having filled the cart with your favorite items.
其他回答
不是最坏的,但也足以造成一些真正的损害。你会惊讶于这一点被忽视的频率有多高。特别是当人们使用这些流行的框架时,
yourwebapp.com/items/edit.php?id=4
yourwebapp.com/items/delete.php?id=4
不确定项的所有者是请求页面的人。 也就是说,你可以登录你的账户,然后在整个应用程序中编辑或删除任何人的项目。
一个简单的检查可以防止很多损坏。
$item = // find your item by the $_GET[ 'id' ];
if( $_SESSION[ 'user_id' ] != $item[ 'user_id' ] ){
// kick em out they dont belong...
}
我们有一个客户要求根据特定的HTTP引用器自动登录。所以你和我必须登录,但如果你点击了一个特定网站的链接,你就会自动以默认用户登录。
2007年,一家相当大的机构的国防部网站出现了错误配置,导致IIS web服务器提供原始代码,主页中有硬编码的用户名/密码和数据库服务器信息。幸运的是,它很快就被抓住了,但我确实目睹了它,这非常令人震惊。不用说,他们的网站被网络工程师关闭了,直到开发人员修复了糟糕的代码。
我认为超级用户访问的空白用户名/密码字段是迄今为止最糟糕的。但我亲眼看到的是
if (password.equals(requestpassword) || username.equals(requestusername))
{
login = true;
}
太糟糕了,一个操作员就有这么大的不同。
一个“安全”的网站,每个页面都是加密的,但登录页面!