《如何安全检测java web应用网站漏洞》由会员分享，可在线阅读，更多相关《如何安全检测java web应用网站漏洞（9页珍藏版）》请在金锄头文库上搜索。
1、如何安全检测如何安全检测 JavaJava WebWeb 应用网站漏洞应用网站漏洞web 开发应用程序（网站） ，是目前应用最广泛的程序。但是开发者的水平参差不齐，导致了各种各样 web 漏洞的出现。本文站在分层架构的角度，分析一下如何在 java web 程序中找到可能出现的种种漏洞。 本文讨论的只是 web 程序上的漏洞，和其它漏洞，是相对独立的。这句话看似废话，实际上却说明了时常被忽略的因素，即：“很多人认为只要我开发 web 程序没有漏洞，web 服务器就安全了” ，事实上，并非如此。一个合格的 web 程序开发人员，应该时刻清楚自己开发的程序会在什么环境中被使用，以及一旦自己的程序产
2、生某种漏洞，最终会导致什么后果。简单的说，web 程序被安装在一台或多台（分布式）web 服务器上，一旦安装成功，就等于在为广大用户提供服务的同时，给入侵者打开了一条或 N 条新的思路。如果服务器管理员刚好对安全配置不了解（事实上，国内这种管理员居多） ，那么只好由我们的程序来守好最后的关卡最后一道防线。 看了本文题目，一定有一部分人会认为， “不就是讲 JSP 漏洞么，用得着披着这么厚的包装么？” ，为了回答这个疑问，我们先看看 JSP 和 ASP 的开发有什么不同吧。在 ASP 时代（ASP，PHP 等语言） ，开发一套系统往往比修改别人已经写好的系统痛苦的多，因为它们把所有的代码（包括链
3、接数据库的代码、执行 SQL 语句的代码、控制页面显示的代码）统统都放在中，我们时常会看到如下代码块： -代码来自某 ASP SHELL- Function GetFileSize(size) Dim FileSize FileSize=size / 1024 FileSize=FormatNumber(FileSize,2) If FileSize 1 then GetFileSize=“KB“ ElseIf FileSize 1024 then GetFileSize=“MB“ Else GetFileSize=“Bytes“ End If End Function - 如果客户的需求变了
4、，要求页面不能使用“”等标签，全部应用“CSS”显示。挂了，把程序员召唤出来，一个一个的改吧。 。 。注意，这里强调下，特指“召唤程序员”才能改，如果是学美工的，只会 HTML、JS、CSS，完了，这活还干不成。而这些只是简单的页面修改，如果客户今天说，MYSQL 服务器承担不了这个数据量，要挂 Oracle，可怜的程序员就要在一片一片的代码海洋里寻找执行 SQL 语句的代码，而每一个文件都可能存放着 SQL 语句，意味着每一个文件都可能在受 SQL 注入的威胁。 而 JSP 采用 MVC 模式分层架构进行开发，就可以把所有的文件分开，根据其用途，分别放在不同的文件夹下（分层） ，每个文件夹下
5、的文件只负责自己的事情。例如数据访问层的代码就放在数据访问层的文件夹下，业务逻辑层的代码也都放在自己的文件夹下，当显示层（这一层是为了把最终的运算结果显示给用户看）的需求发生变化，就像前面的客户需求，我们只要修改这一层的文件就是了，其他层的代码根本不需要动，而修改者也不需要懂得其它层的代码。 代码分层了，意味着漏洞也在跟着分层，我们寻找 JSP 漏洞的思路也要跟着分层，才能与时俱进。 下面在讲述寻找漏洞的过程中，本文就拿一个简单的分层架构例子来做样板。样板程序的名称为“XX 文章系统” ，系统使用了 STRUTS 框架，和安全有关的层分为： “DB 层” ，这一层存放了链接数据库的字符串，以及
6、JdbcTemplate 类，直接访问数据库。因为在 java 中，执行 SQL 语句的函数按照返回值可以分为三类，所以在这一层定义了 JDBC 模版类（JdbcTemplate） ，每一次使用操作数据库时都要执行这一层的三个方法其中一个。 “DAO 层（Data Access Object 数据访问对象层） ” ，从安全角度上看，这一层存放了 SQL 语句（并不执行 SQL 语句，语句传给 DB层执行） 。这一层调用“DB 层”访问数据库，它只知道“DB 层”的存在，不知道数据库的存在。 “SERVICE 层” ，业务逻辑层，因为一个业务的实现，并不是一次数据库访问就可以完成的，所以这一层通
7、过 N 次调用“DAO 层的方法”实现业务逻辑，它只知道“DAO 层”的存在，不知道“DB 层”和数据库的存在。 “ACTION 层” ，调用业务逻辑层，根据返回的结果，控制 JSP 页面显示。它只知道业务层的存在。这一层是入侵者的攻击平台。 “Form 层” ，把用户 POST 提交的信息封装成 Form 对象，经过验证后提交给 ACTION 层处理。 “JSP 层”(显示层)，这一层是最终显示给用户看的页面，同时也是入侵者的攻击平台。 用户通过访问 ACTION 层，自动会发生：“ACTION 调用SERVICE，SERVICE 调用 DAO，DAO 调用 DB，DB 执行 SQL 语句返
8、回结果给 DAO，DAO 返回给 SERVICE，SERVICE 返回给 ACTION，ACTION 把数据显示到 JSP 里返回给用户” 。 有了样板，我们来分析这套程序中可能出现的各种 web 漏洞。 1、SQL 注入漏洞 从 SQL 注入漏洞说起吧，在 web 漏洞里，SQL 注入是最容易被利用而又最具有危害性的。怎么快速的找到呢？先分析流程，就拿用户查看文章这个流程为例：用户访问一个 action，告诉它用户想看 ID 为 7 的文章，这个 action 就会继续完成前面所说的流程。如果是 ASP 程序，这就是最容易产生问题的时候，ASP 是弱类型，接到参数后不需要转换类型，就和 SQ
9、L 语句连加起来。但是 JSP 就不一样，JSP 是强类型的语言，接受有害的参数后：对于GET 请求（直接在地址栏访问页面） ，如果这里要的是 int 型，即使不懂安全的程序员，也会把它（文章的 ID）立刻转换成 int，因为这里转换后在后面的处理中会更容易操作，而这时程序就出错了；对于 POST 请求，如果这里要的是 int 型，程序会在把它封装成Form 对象时，因为自动要进行类型转化，同样发生错误，这两种错误发生后，根本不会访问后面的流程就跳出了，或许这就是 JSP 天生的安全性。所以，通常提交的变量是 int 时，不会发生问题，问题会出现在 string 参数这里，如果要查看某用户的信
10、息，程序可能会让你提交如下参数：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
11、 层直接交给了 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
12、的 executequery()方法执行，导致了 SQL 注入。 分析了这么半天，有读者会问：“难道我要费这么大的力气才能找到漏洞么？” 。的确，通常在 ASP 程序里找注入时的思路就是这样子，但是我们现在是在使用了开发模式分层架构的 JSP 程序里，应该按照分层架构的思维去找漏洞。在回答这个问题之前，我们还得绕个弯子，看看怎么在这里预防 SQL 注入（java 始终都是这么优美，它不会直接告诉你答案，而是一层一层的让你拨开云雾） 。 刚才分析流程，是从正向分析的，从用户输入到产生漏洞，我们在防御的时候，不妨倒过来看看，从 DB 层入手。JdbcTemplate调用执行 SQL 语句，可以有两
13、个类供我们选择，一个是Statement，另一个就是预处理的 Statement，两者有着效率上和安全上的显著差别。在效率上，只要数据库支持预处理技术（sqlserver，mysql，oracle 等都支持，只有少数 access 等不支持） ，就会在大量执行 SQL 语句时增加速度；在安全上，使用预处理，会把接受的参数也经过预处理，从而不会作为 SQL 语句的一部分执行，而是仅仅作为 SQL 语句中的参数部分内容被执行。一旦 DB 层使用了预处理，DAO 层的 SQL 语句也会发生变化，成为这个样子： public Object findByUsername(String username)
14、 JdbcTemplate jt=new JdbcTemplate(); String sql = “select * from Users where username=?“; List list = jt.query(sql,new Object1username); . 这样，SQL 注入就和我们的程序几乎无关了，注意我说的是几乎，而不是全部。知道了怎么防御，于是一切在这里变的简单极了，我们应该直接去 DB 层找到 JdbcTemplate，看看代码，一旦使用了 Statement，很好，这个系统十有八九有漏洞，下面要做的是使用 Editplus 搜索“request.getParame
15、ter” 。没有使用预处理的系统，可能会在 action 层进行防御，对参数过滤，但总有防御不到的时候，因为战线拉的太长了，每一个 action 里都可能接受参数并存在漏洞。 还有一种情况，系统一部分使用了预处理，一部分没有，这样的情况可能是因为项目赶的比较仓促，人员没有经过正规培训，最后艰难的整合到了一起。这种情况也好办，直接在 DAO 层搜索（“ ）或（“） ，这些符号用于和字符串变量连加，拼 SQL 语句，肯定是这些语句之后的代码使用了 Statement。然后再往上层找，看看哪个 action 调用了这个有问题的 dao 类，也可能发生 SQL 注入。即使系统使用了预处理，别忘了，程序
16、给客户使用后，客户有权利去扩展的。程序拿到客户那里，客户有了新的需求，而这个需求又不大，很可能不愿意花钱重新雇人来实现扩展功能，在这个时候也可能出现问题，客户使用自己的程序员扩展 AJAX 功能，这个程序员因为怕出问题，不敢动源程序，就在 web.xml 里加了一个servlet，这个 servlet 直接去调用 conn。可怕的事情发生了。所以，我们的搜索漏洞规则中又加上了一条，在非 dao 层的文件中，搜索“select，update，delete”等字符串。 2、暴露程序信息漏洞 这个漏洞是怎么来的呢？我们需要从异常说起。有经验的入侵者，可以从 JSP 程序的异常中获取很多信息，比如程序的部分架构、程序的物理路径、SQL 注入爆出来的信息等，这个漏洞很容易防御，却很难快速定位漏洞文件。出现这样漏洞的时候，通常是我们在写代码的时候，
