进来讨论者有分，关于JSP安全问题

freev 2003-12-02 04:10:59

先转载一篇文章，希望各位能够热烈讨论

JSP应用的安全问题

仙人掌工作室

01-9-21 下午 05:25:46

--------------------------------------------------------------------------------

一、概述

当网络编程越来越方便，系统功能越来越强大，安全性却指数倍地下降。这恐怕就是网络编程的不幸和悲哀了。各种动态内容生成环境繁荣了WWW，它们的设计目标就是为了给开发者更多的力量，给最终用户更多的方便。正因为如此，系统设计师和开发者必须明确地把安全问题作为一个考虑因素，事后追悔很难奏效。

从安全的角度来看，服务器端WWW应用的弱点来源于各种各样的交互能力和传输通道。它们是攻击者直接可以用来影响系统的工具。在攻击者寻找和利用系统安全漏洞时，它们总是给系统安全带来压力。对付所有这些攻击的通用防卫策略就是所谓的输入验证。

从同一层面考虑，主要有两种设计上的错误导致了安全方面的问题：

· 拙劣的访问控制，以及

· 对部署环境作隐含的假设。

在有关安全的文献中，针对访问控制问题有着许多深入的分析。这里我们要讨论的是底层实现（代码和配置）上的安全管理问题，讨论的环境是JSP。或者说，我们将讨论恶意的用户输入伪装自身以及改变应用预定行为的各种方法，考虑如何检验输入合法性以及减少对信息和应用接口的不受欢迎的探测。

二、JSP概述

JSP技术允许把Java代码逻辑嵌入到HTML和XML文档之内，为创建和管理动态WWW内容带来了方便。JSP页面由JSP引擎预先处理并转换成Java Servlet，此后如果出现了对JSP页面的请求，Web服务器将用相应的Servlet输出结果作为应答。虽然JSP和Servlet在功能上是等价的，但是，和Servlet相比，JSP的动态内容生成方法恰好相反：JSP是把Java代码嵌入到文档之中，而不是把文档嵌入到Java应用之中。为访问外部功能和可重用的对象，JSP提供了一些用来和JavaBean组件交互的额外标记，这些标记的语法和HTML标记相似。值得注意的是：HTML语法属于JSP语法的一个子集（一个纯HTML文档是一个合法的JSP页面），但反过来不一定正确。特别地，为了便于动态生成内容和格式，JSP允许在标记之内嵌入其他标记。例如，下面是一段合法的JSP代码：

<A HREF = "<%= request.getRemoteUser() %>">

从本文后面可以看到，这种结构增加了安全问题的复杂性。

与CGI相比，JSP具有更好的性能和会话管理（即会话状态持久化）机制。这主要通过在同一个进程之内运用Java线程处理多个Servlet实现，而CGI一般要求为每一个请求分别创建和拆除一个进程。

三、安全问题

由于完全开放了对服务器资源的访问，从JSP页面转换得到的不安全Servlet可能给服务器、服务器所在的网络、访问页面的客户机之中的任意一个或全体带来威胁，甚至通过DDoS或蠕虫分布式攻击，还可能影响到整个Internet。人们往往假定，Java作为一种类型安全的、具有垃圾收集能力的、具有沙箱（Sandbox）机制的语言，它能够奇迹般地保证软件安全。而且事实上，许多在其他语言中存在的低层次安全问题，比如缓冲或堆溢出，很少给Java程序带来危害。然而，这并不意味着人们很难写出不安全的Java程序，特别是对编写Servlet来说。验证输入和控制对资源的访问是始终必须关注的问题。另外，JSP的体系结构相当复杂，其中包含许多相互协作的子系统。这些子系统之间的交互常常是安全隐患的根源。除此之外，虽然现在所有的JSP实现都围绕着Java，但JSP规范允许几乎所有其他语言扮演这个角色。这样，这些替代语言的安全问题也必须加以考虑。

简而言之，在JSP系统中产生安全漏洞的机会是相当多的。下面我们将讨论它们中最常见的一部分。

四、非置信用户输入的一般问题

非置信的用户输入（Untrusted User Input）实际上包含了所有的用户输入。用户输入来源于客户端，可以通过许多不同的途径到达服务器端，有时甚至是伪装的。为JSP服务器提供的用户输入包括（但不限于）：

· 请求URL的参数部分，

· HTML表单通过POST或GET请求提交的数据，

· 在客户端临时保存的数据（也就是Cookie），

· 数据库查询，

· 其它进程设置的环境变量。

用户输入的问题在于，它们由服务器端的应用程序解释，所以攻击者可以通过修改输入数据达到控制服务器脆弱部分的目的。服务器的脆弱部分常常表现为一些数据访问点，这些数据由用户提供的限定词标识，或通过执行外部程序得到。

JSP能够调用保存在库里面的本地代码（通过JNI）以及执行外部命令。类Runtime提供了一个exec()方法。exec()方法把它的第一个参数视为一个需要在独立的进程中执行的命令行。如果这个命令字符串的某些部分必须从用户输入得到，则用户输入必须先进行过滤，确保系统所执行的命令和它们的参数都处于意料之内。即使命令字符串和用户输入没有任何关系，执行外部命令时仍旧必须进行必要的检查。在某些情况下，攻击者可能修改服务器的环境变量影响外部命令的执行。例如，修改path环境变量，让它指向一个恶意的程序，而这个恶意程序伪装成了exec()所调用程序的名字。为了避免这种危险，在进行任何外部调用之前显式地设置环境变量是一种较好的习惯。具体的设置方法是：在exec()调用中，把一个环境变量的数组作为第二个参数，数组中的元素必须是name=value格式。

当用户输入用来标识程序打开的任意类型的输入/输出流时，类似的问题也会出现。访问文件、数据库或其他网络连接时不应该依赖于未经检验的用户输入。另外，打开一个流之后，把用户输入直接发送给它是很不安全的。对于SQL查询来说这一点尤其突出。下面访问JDBC API的JSP代码片断很不安全，因为攻击者可以在他提交的输入中嵌入分隔命令的字符，从而达到执行危险命令的目的：

<%@ page import="java.sql.*" %>  <% Statement stmt = connection.getStatement(); String query = "SELECT * FROM USER_RECORDS WHERE USER = " + request.getParameter("username"); ResultSet result = Statement.executeQuery(query); %>

如果username包含一个分号，例如：

http://server/db.jsp? username=joe;SELECT%20*%20FROM%20SYSTEM_RECORDS

一些版本的SQL Server会忽略整个查询，但还有一些版本的SQL Server将执行两个命令。如果是后者，攻击者就可以访问原本没有资格访问的数据库资源（假定Web服务器具有访问权限）。

进行适当的输入检验可以防止这类问题出现。

...全文