分层架构下寻找java web漏洞

作者：空虚浪子心[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的代码：
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注入。

　　即使系

补充：软件开发 , Java ,