分层架构下寻找java web漏洞(一)

2014-11-23 23:14:01 · 作者: · 浏览: 0

作者:空虚浪子心[X.G.C] http://cnxhacker.net
来源:IT168
原文地址:http://safe.it168.com/ss/2007-09-06/200709060953563.shtml

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

  本文讨论的只是web程序上的漏洞,和其它漏洞,是相对独立的。这句话看似废话,实际上却说明了时常被忽略的因素,即:“很多人认为只要我开发web程序没有漏洞,web服务器就安全了”,事实上,并非如此。一个合格的web程序开发人员,应该时刻清楚自己开发的程序会在什么环境中被使用,以及一旦自己的程序产生某种漏洞,最终会导致什么后果。简单的说,web程序被安装在一台或多台(分布式)web服务器上,一旦安装成功,就等于在为广大用户提供服务的同时,给入侵者打开了一条或N条新的思路。如果服务器管理员刚好对安全配置不了解(事实上,国内这种管理员居多),那么只好由我们的程序来守好最后的关卡最后一道防线。

  看了本文题目,一定有一部分人会认为,“不就是讲JSP漏洞么,用得着披着这么厚的包装么?”,为了回答这个疑问,我们先看看JSP和ASP的开发有什么不同吧。在ASP时代(ASP,PHP等语言),开发一套系统往往比修改别人已经写好的系统痛苦的多,因为它们把所有的代码(包括链接数据库的代码、执行 SQL语句的代码、控制页面显示的代码)统统都放在<%......%>中,我们时常会看到如下代码块:

-----------代码来自某ASP木马-----------
Function GetFileSize(size)
Dim FileSize
FileSize=size / 1024
FileSize=FormatNumber(FileSize,2)
If FileSize < 1024 and FileSize > 1 then
GetFileSize=""& FileSize & " KB"
ElseIf FileSize >1024 then
GetFileSize=""& FormatNumber(FileSize / 1024,2) & " MB"
Else
GetFileSize=""& Size & " Bytes"
End If
End Function
----------------------------------------

  如果客户的需求变了,要求页面不能使用“”等标签,全部应用“CSS”显示。挂了,把程序员召唤出来,一个一个的改吧。。。注意,这里强调下,特指“召唤程序员”才能改,如果是学美工的,只会HTML、JS、CSS,完了,这活还干不成。而这些只是简单的页面修改,如果客户今天说,MYSQL服务器承担不了这个数据量,要挂Oracle,可怜的程序员就要在一片一片的代码海洋里寻找执行SQL语句的代码,而每一个文件都可能存放着SQL语句,意味着每一个文件都可能在受SQL注入的威胁。

  而JSP采用MVC模式分层架构进行开发,就可以把所有的文件分开,根据其用途,分别放在不同的文件夹下(分层),每个文件夹下的文件只负责自己的事情。例如数据访问层的代码就放在数据访问层的文件夹下,业务逻辑层的代码也都放在自己的文件夹下,当显示层(这一层是为了把最终的运算结果显示给用户看)的需求发生变化,就像前面的客户需求,我们只要修改这一层的文件就是了,其他层的代码根本不需要动,而修改者也不需要懂得其它层的代码。

  代码分层了,意味着漏洞也在跟着分层,我们寻找JSP漏洞的思路也要跟着分层,才能与时俱进。

  下面在讲述寻找漏洞的过程中,本文就拿一个简单的分层架构例子来做样板。样板程序的名称为“XX文章系统”,系统使用了STRUTS框架,和安全有关的层分为:

  “DB层”,这一层存放了链接数据库的字符串,以及JdbcTemplate类,直接访问数据库。因为在java中,执行SQL语句的函数按照返回值可以分为三类,所以在这一层定义了JDBC模版类(JdbcTemplate),每一次使用操作数据库时都要执行这一层的三个方法其中一个。

  “DAO层(Data Access Object数据访问对象层)”,从安全角度上看,这一层存放了SQL语句(并不执行SQL语句,语句传给DB层执行)。这一层调用“DB层”访问数据库,它只知道“DB层”的存在,不知道数据库的存在。

  “SERVICE层”,业务逻辑层,因为一个业务的实现,并不是一次数据库访问就可以完成的,所以这一层通过N次调用“DAO层的方法”实现业务逻辑,它只知道“DAO层”的存在,不知道“DB层”和数据库的存在。
“ACTION层”,调用业务逻辑层,根据返回的结果,控制JSP页面显示。它只知道业务层的存在。这一层是入侵者的攻击平台。

  “Form层”,把用户POST提交的信息封装成Form对象,经过验证后提交给ACTION层处理。

  “JSP层”(显示层),这一层是最终显示给用户看的页面,同时也是入侵者的攻击平台。

  用户通过访问ACTION层,自动会发生:“ACTION调用SERVICE,SERVICE调用DAO,DAO调用DB,DB执行SQL语句返回结果给 DAO,DAO返回给SERVICE,SERVICE返回给ACTION,ACTION把数据显示到JSP里返回给用户”。

  有了样板,我们来分析这套程序中可能出现的各种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的