JSP应用的安全问题_JSP编程

一、概述  
当网络编程越来越方便，系统功能越来越强大，安全性却指数倍地下降。这恐怕就是网络编程的不幸和悲哀了。各种动态内容生成环境繁荣了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.*" %> <!-- 这里加上一些打开SQL Server连接的代码 --> <% 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服务器具有访问权限）。  
进行适当的输入检验可以防止这类问题出现。  
五、输入检验  
从安全的角度来看，输入检验包括对来自外部数据源（非置信数据源，参见前面说明）的数据进行语法检查，有时还要进行语义检查。依赖于应用的关键程度和其他因素，作为输入检验结果而采取的动作可能是下面的一种或者多种：  
· 忽略语法上不安全的成分，  
· 用安全的代码替换不安全的部分，  
· 中止使用受影响的代码，  
· 报告错误，  
· 激活一个入侵监测系统。  
输入检验可以按照以下两种模式之一进行：列举不安全的字符并拒绝它们；定义一组安全的字符，然后排除和拒绝不安全的字符。这两种模式分别称为正向和反向输入过滤。一般地，正向输入过滤更简单和安全一些，因为许多时候，要列举出服务器端应用、客户端浏览器、Web服务器和操作系统可能误解的字符并不是一件容易的事情。  
请参见本文下面“通过嵌入标记实现的攻击”部分中输入检验的例子，这个例子示范了如何避免误解恶意提交的输入内容。  
六、GET请求和Cookie中的敏感数据  
就象CGI协议所定义的，把请求数据从客户端传输到服务器端最简单的方法是GET请求方法。使用GET请求方法时，输入数据附加到请求URL之后，格式如下：  
URL[?name=value[&name=value[&...]]]
显然，对于传输敏感数据来说，这种编码方式是不合适的，因为通常情况下，整个URL和请求字符串都以明文方式通过通信通道。所有路由设备都可以和服务器一样记录这些信息。如果要在客户请求中传输敏感数据，我们应该使用POST方法，再加上一种合适的加密机制（例如，通过SSL连接）。从JSP引擎的角度来看，在很大程度上，使用哪种传输方法无关紧要，因为两者的处理方式一样。  
在WWW的发展过程中，Netscape引入了Cookie的概念。Cookie是服务器保存到客户端的少量信息，服务器提取这些信息以维持会话状态或跟踪客户端浏览器的活动。JSP提供了一个response隐含对象的addCookie()方法，用来在客户端设置Cookie；提供了一个request()对象的getCookie()方法，用来提取Cookie的内容。Cookie是javax.servlet.http.Cookie类的实例。由于两个原因，如果把敏感数据保存到Cookie，安全受到了威胁：第一，Cookie的全部内容对客户端来说都是可见的；第二，虽然浏览器一般不提供伪造Cookie的能力，但没有任何东西能够阻止用户用完全伪造的Cookie应答服务器。  
一般而言，任何客户端浏览器提交的信息都不可以假定为绝对安全。  
七、通过嵌入标记实现的攻击  
CERT Advisory CA-2000-02描述了客户在请求中嵌入恶意HTML标记的问题。这个问题一般被称为“cross site scripting”问题，但它的名字有些用词不当，因为它不仅仅和脚本有关，同时，它和“跨越网站”（cross site）也没有什么特别的关系。不过，这个名字出现时，问题还没有被人们广泛了解。  
这种攻击通常包含一个由用户提交的病态脚本，或者包含恶意的HTML（或XML）标记，JSP引擎会把这些内容引入到动态生成的页面。这种攻击可能针对其他用户进行，也可能针对服务器，但后者不太常见。“cross site scripting”攻击的典型例子可以在论坛服务器上看到，因为这些服务器允许用户在自己提交的文章中嵌入格式化标记。通常，被滥用的标记是那些能够把代码嵌入到页面的标记，比如<SCRIPT>、<OBJECT>、<APPLET>和<EMBED>。另外还有一些标记也会带来危险，特别地，<FORM>可能被用于欺骗浏览者暴露敏感信息。下面是一个包含恶意标记的请求字符串的例子：  
http://server/jsp_script.jsp?poster=evilhacker＆ message=<SCRIPT>evil_code</SCRIPT>
要防止出现这种问题当然要靠输入检查和输出过滤。这类检查必须在服务器端进行，不应依赖于客户端脚本（比如JavaScript），因为没有任何东西能够阻止用户逃避客户端检验过程。  
下面的代码片断示范了如何在服务器端检查嵌入的标记：  
<!-- HTML代码结束 --><% String message = request.getParameter("message"); message = message.replace ('<','_'); message = message.replace ('>','_'); message = message.replace ('"','_'); message = message.replace (''','_'); message = message.replace ('%','_'); message = message.replace (';','_'); message = message.replace ('(','_'); message = message.replace (')','_'); message = message.replace ('&','_'); message = message.replace ('+','_'); %><p>你提交的消息是：<hr/><tt><%= message %></tt><hr/></p><!-- 下面加上其他HTML代码 -->
由于要列举出所有不合法的字符比较困难，所以更安全的方法是进行正向过滤，即除了那些确实允许出现的字符之外（例如[A-Za-z0-9]），丢弃（或者转换）所有其他字符。  
八、关于JavaBean的说明  
JSP按照JavaBean规范描述的一系列约定，在JSP页面中快速、方便地访问可重用的组件（Java对象）。每个JavaBean组件封装了一些可以不依赖于调用环境而独立使用的数据和功能。Bean包含数据成员（属性），并通过Get和Set方法实现访问这些属性的标准API。  
为快速初始化指定Bean的所有属性，JSP提供了一种快捷方式，即在查询字符串中提供name=value对，并让它匹配目标属性的名字。考虑下面这个使用Bean的例子（以XML格式显示）：  
<jsp:useBean id="myBasket" class="BasketBean"> <jsp:setProperty name="myBasket" property="*"/> <jsp:useBean> <html> <head><title>你的购物篮</title></head> <body> <p> 你已经把商品： <jsp::getProperty name="myBasket" property="newItem"/> 加入到购物篮 <br/> 金额是$ <jsp::getProperty name="myBasket" property="balance"/> 准备 <a href="checkout.jsp">付款</a>
注意在setProperty方法调用中使用的通配符号“*”。这个符号指示JSP设置查询字符串中指定的所有属性的值。按照本意，这个脚本的调用方式如下：  
http://server/addToBasket.jsp?newItem=ITEM0105342
正常情况下，HTML表单构造的查询字符串就是这种形式。但问题在于，没有任何东西能够防止用户设置balance属性：  
http://server/addToBasket.jsp? newItem=ITEM0105342&balance=0
处理页面的<jsp:setProperty>标记时，JSP容器会把这个参数映射到Bean中具有同样名字的balance属性，并尝试把该属性设置为0。  
为避免出现这种问题，JSP开发者必须在Bean的Set和Get方法中实现某种安全措施（Bean必须对属性进行强制的访问控制），同时，在使用<jsp:setProperty>的通配符时也应该小心谨慎。  
九、实现上的漏洞与源代码安全  
无论是哪一种JSP实现，在一定的阶段，它们的某些版本都会出现给系统带来危险的安全隐患，即使JSP开发者遵从了安全编程惯例也无济于事。例如，在Allaire的JRun的一个版本中，如果请求URL包含字符串“.jsp%00”作为JSP脚本扩展名的一部分，服务器不会忽略null字节，它会把页面视为一个静态的非JSP页面之类的东西。这样，服务器会请求操作系统打开该页面，而这时null字节却被忽略，结果提供给用户的是JSP页面的源代码而不是页面的执行结果。  
类似地，Tomcat的一个版本也有一个安全隐患。只要请求类如下面的格式，它会让攻击者看到JSP页面的源代码：  
http://server/page.js%2570
这里的骗局在于，%25是URL编码的“%”，而70是“p”的十六进制值。Web服务器不会调用JSP处理器（因为URL没有以“.jsp”结尾），但静态文件处理器会设法把URL映射到正确的文件名字（再一次解码URL）。  
另外，许多Web服务器和JSP实现都带有示范脚本，这些示范脚本常常包含安全隐患。在把服务器部署到一个不无恶意的环境（即Internet）之前，禁止对所有这些脚本的访问有利于安全。  
简而言之，JSP开发者应该清楚：在自己正在开发的平台上，当前有哪些安全隐患。订阅BUGTRAQ和所有供应商提供的邮件列表是跟踪这类信息的好方法。  
结束语  
JSP和任何其他强大的技术一样。如果要保证被部署系统的安全和可靠，应用JSP时必须小心谨慎。在这篇文章中，我们简要地讨论了JSP脚本中常常出现的代码和配置级安全问题，提出了降低由此带来的安全风险的建议。