科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网安全频道安全检测Java Web应用网站漏洞(下)

安全检测Java Web应用网站漏洞(下)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

web开发应用程序(网站),是目前应用最广泛的程序。但是开发者的水平参差不齐,导致了各种各样web漏洞的出现。本文站在分层架构的角度,分析一下如何在java web程序中找到可能出现的种种漏洞。

作者:论坛整理 来源:zdnet网络安全 2008年4月14日

关键字: 漏洞 网站 Web安全 安全检测

  • 评论
  • 分享微博
  • 分享邮件
 有了样板,我们来分析这套程序中可能出现的各种web漏洞。

    1、SQL注入漏洞

        从SQL注入漏洞说起吧,在web漏洞里,SQL注入是最容易被利用而又最具有危害性的。怎么快速的找到呢?先分析流程,就拿用户查看文章这个流程为例:用户访问一个action,告诉它用户想看ID为7的文章,这个action就会继续完成前面所说的流程。

        如果是ASP程序,这就是最容易产生问题的时候,ASP是弱类型,接到参数后不需要转换类型,就和SQL语句连加起来。但是JSP就不一样,JSP是强类型的语言,接受有害的参数后:对于GET请求(直接在地址栏访问页面),如果这里要的是int型,即使不懂安全的程序员,也会把它(文章的ID)立刻转换成int,因为这里转换后在后面的处理中会更容易操作,而这时程序就出错了;对于POST请求,如果这里要的是int型,程序会在把它封装成Form对象时,因为自动要进行类型转化,同样发生错误,这两种错误发生后,根本不会访问后面的流程就跳出了,或许这就是JSP天生的安全性。所以,通常提交的变量是int时,不会发生问题,问题会出现在string参数这里,如果要查看某用户的信息,程序可能会让你提交如下参数:showuser.do?    username=kxlzx。问题来了,因为这里是string类型,所以不懂安全的程序员顶多会判断一下是不是空,就连加成为SQL语句。有漏洞的程序大概会写成这个样子:

    ACTION的代码:
showuser.do
    String username = null;
    username = request.getParameter("username");
    Service service = new Service();
    service.findByUsername(username);
    得到参数后调用service,service层直接交给了Dao层,dao的代码:
    public Object findByUsername(String username)
     {
    JdbcTemplate jt=new JdbcTemplate();
    String sql = "select * from Users where username=’"+username"’";
    List list = jt.query(sql);
    ...................
     }

       dao调用了DB层的JdbcTemplate,把SQL语句拼好后,传给了JdbcTemplate去执行。不用再看这里的JdbcTemplate,就可以知道里面的代码使用了Statement的executequery()方法执行,导致了SQL注入。

       分析了这么半天,有读者会问:“难道我要费这么大的力气才能找到漏洞么?”。的确,通常在ASP程序里找注入时的思路就是这样子,但是我们现在是在使用了开发模式分层架构的JSP程序里,应该按照分层架构的思维去找漏洞。在回答这个问题之前,我们还得绕个弯子,看看怎么在这里预防SQL注入(java始终都是这么优美,它不会直接告诉你答案,而是一层一层的让你拨开云雾)。

        刚才分析流程,是从正向分析的,从用户输入到产生漏洞,我们在防御的时候,不妨倒过来看看,从DB层入手。JdbcTemplate调用执行SQL语句,可以有两个类供我们选择,一个是Statement,另一个就是预处理的Statement,两者有着效率上和安全上的显著差别。在效率上,只要数据库支持预处理技术(sqlserver,mysql,oracle等都支持,只有少数access等不支持),就会在大量执行SQL语句时增加速度;在安全上,使用预处理,会把接受的参数也经过预处理,从而不会作为SQL语句的一部分执行,而是仅仅作为SQL语句中的参数部分内容被执行。一旦DB层使用了预处理,DAO层的SQL语句也会发生变化,成为这个样子: 
    public Object findByUsername(String username)
     {
    JdbcTemplate jt=new JdbcTemplate();
    String sql = "select * from Users where username=?";
    List list = jt.query(sql,new Object[1]{username});
    ...................
    }

        这样,SQL注入就和我们的程序几乎无关了,注意我说的是几乎,而不是全部。知道了怎么防御,于是一切在这里变的简单极了,我们应该直接去DB层找到JdbcTemplate,看看代码,一旦使用了Statement,很好,这个系统十有八九有漏洞,下面要做的是使用Editplus搜索“request.getParameter”。没有使用预处理的系统,可能会在action层进行防御,对参数过滤,但总有防御不到的时候,因为战线拉的太长了,每一个action里都可能接受参数并存在漏洞。

        还有一种情况,系统一部分使用了预处理,一部分没有,这样的情况可能是因为项目赶的比较仓促,人员没有经过正规培训,最后艰难的整合到了一起。这种情况也好办,直接在DAO层搜索("’)或(’"),这些符号用于和字符串变量连加,拼SQL语句,肯定是这些语句之后的代码使用了Statement。然后再往上层找,看看哪个action调用了这个有问题的dao类,也可能发生SQL注入。
       即使系统使用了预处理,别忘了,程序给客户使用后,客户有权利去扩展的。程序拿到客户那里,客户有了新的需求,而这个需求又不大,很可能不愿意花钱重新雇人来实现扩展功能,在这个时候也可能出现问题,客户使用自己的程序员扩展AJAX功能,这个程序员因为怕出问题,不敢动源程序,就在web.xml里加了一个servlet,这个servlet直接去调用conn。可怕的事情发生了。所以,我们的搜索漏洞规则中又加上了一条,在非dao层的文件中,搜索“select,update,delete”等字符串。

    2、暴露程序信息漏洞

        这个漏洞是怎么来的呢?我们需要从异常说起。有经验的入侵者,可以从JSP程序的异常中获取很多信息,比如程序的部分架构、程序的物理路径、SQL注入爆出来的信息等,这个漏洞很容易防御,却很难快速定位漏洞文件。出现这样漏洞的时候,通常是我们在写代码的时候,少了一些可能性的考虑而导致的。这样的问题都是经验造成的,而寻找漏洞也要通过经验加运气(要有仙缘。。。),我个人技术有限,就不多说了。防御的方法就是在程序中加上“Exception层”,自定义异常,把系统产生的异常统统包装起来,不要放过任何一个可能产生异常的地方。像腾讯的异常就包装的很好“对不起,今天的注册人数已经达到十万,请您明天再来。。。”,废话,日注册量都十万,还让不让人活啦,铁定是程序发生了异常,不敢让各位大大们看到真实的面孔。

   3、AJAX暴露出来的漏洞

        前面讲SQL注入的时候说过的例子就是一个典型的情况,因为大多数网站不是在开发时就拥有Ajax技术的,都是后来看大家都用了,赶时髦加上。但是在加上的同时没有意识到,在web上增加一个文件,就等于扩展了一点攻击面。

    4、业务逻辑漏洞

        这个词看起来挺抽象的,他和“暴露程序信息漏洞”有很多共同点,看名字就知道,应该是存在于业务逻辑层(service层)的漏洞。这样的漏洞都和程序的运行逻辑有关,举一个例子。

        小王给小李转账,在业务层的流程应该是这样子的,首先在小王的账上扣除一百元,之后在小李的账上增加一百元。
        这个过程需要执行至少两条SQL语句,也就是调用至少两次dao方法,而一旦调用中间出现问题(产生异常),就应该立刻回滚而不是跳转到异常处理机制。大家都应该想到使用“事务处理”,是的,在一个大型复杂的项目里,一定要进行事务处理,一旦事务处理控制的不好,麻烦就大了。这就是它和“暴露程序信息漏洞”的共同点,发现的时候,要凭经验和运气。

    5、XSS漏洞

        这个漏洞也影响深远,想要发现这样的漏洞,除了在页面上进行测试外,还要从流程上入手。用户输入有害信息后,信息保存到数据库,从数据库中读出来丢给用户时产生漏洞。也就是说我们有两个过程可以拦截,就是保存到数据库时,和从数据库读出来后交给用户时。最快的方法是直接打开数据库查看数据,如果数据没有经过编码直接放进了数据库,那么可能性就有了一半。剩下的一半更简单,在action层搜索转码常用的字符,如果没有,就很容易发现漏洞。即使有,也不用着急,在action层里慢慢找,很可能还有漏网之鱼。

    6、页面层的逻辑漏洞

        此类漏洞涵盖面很大,包括“暴露不该暴露的数据”、“权限控制的不精确”、“方便客户的同时存在安全隐患”等等。这类漏洞就只能靠着自己的经验,使用系统的每一个细小功能来寻找。我给出几个例子供大家参考。

       例1,“找回密码”功能,这个功能是为了方便客户的,可以通过一些客户之前确认的信息而获得客户的身份验证。有些程序的逻辑是这样的,“请输入VIP用户名”--(判断VIP用户不存在)--“请输入提示问题答案”--显示用户密码或提供修改密码的链接。第一步,入侵者可以获得VIP用户名是否存在,进而获取密码,第二步,一旦用户留的问题比较弱智,就等于告诉别人自己的密码。

        例2,用户列表功能,试想,普通用户闲着没事看用户列表做什么?这个功分明是为了方便入侵者搜集用户名的。

        例3,不要把防护交给JS,谁告诉我们使用JS可以防止用户做某些操作的?这简直是陷阱,JS只能防护普通用户而已,永远不要相信客户端提交上来的数据,我见到有人的系统在限制上传文件时,仅仅在JS里做了防护,这不是自欺欺人么?

        Web漏洞层出不穷,即使不存在以上漏洞,也别高兴的太早,我们现在使用的技术,只能防范目前上了台面的攻击,或许今天你的系统固若金汤,明天就出现了新的攻击方法。就像04年突然出现的“上传文件”漏洞,在写代码的时候,谁能想到这里还会出现问题?本文中,我仅仅是根据自己的一些经验,以及一时灵感获得的思路,给大家抛砖引玉来的,文中一定有没有写到的地方,而从分层架构的角度去看漏洞的思想才刚刚开始,希望每一位读者在自己的心里都有一翻序曲。期待大家文明的踢场子和鼓励。
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章