按照返回值可以分为三类,所以在这一层定义了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始终都是这么优美,它不