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

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


当前回答

有一家银行通过其网站提供一些服务。开发人员考虑了任何作为整个系统的有效用户登录的人,他们使用URL来识别账号,因此只需更改URL上的ID,就可以查看其他账户的余额。

对于认为身份验证和授权是一回事的web开发人员来说,这是非常糟糕的。

此外,银行不通过其网站转账也很好,否则有些人会很富有;-)

其他回答

在我以前的学校,他们把用户密码以明文形式存储在cookie中。

这本身就很可怕,但更糟糕的是,他们把它们储存在饼干里供*.大学。当然,现在所有学生和员工的页面都在university.edu.au/~user这样的网站上。

<?php

var_dump($_COOKIE); // oops.

我投票给Ken Thompson的UNIX“后门”。

这里有一个链接,有人可以从中了解更多信息: 汤普森木马编译器

我之所以认为这是最糟糕的,是因为在那个时候,法官们认为,在这种事情上取得进展的最好方法是公开讨论。

这一切只是教会了一群脚本小子一个新的非常强大的技巧。

"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.

public class AuthenticationServlet extends HttpServlet
{
    private String userName;
    private String password;

    protected doPost(HttpServletRequest req, HttpServletResponse resp)
           throws ServletException, IOException
    {
        userName = request.getParameter("userName");
        password = request.getParameter("password");
        authenticateUser(userName,password);
        ......
    }
}

显然,正如有人在自动化负载测试中发现的那样,单例和缺乏同步会导致安全问题。

我的银行曾经在我的借记卡上发现了一笔“可疑交易”。他们建议我取消它,买一个新的。

在等待新卡的时候,我需要取钱。于是我走进银行,把我的旧卡给了那位女士,并解释说:“这张卡最近被取消了,但我需要一些钱。你能从这个账户里取点钱吗?”

当我走出银行时,口袋里揣着现金,我意识到我刚刚用一张注销的卡从一个账户里取了钱,而没有被要求出示任何形式的身份证明。