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 代码： “ 从本文后面可以看到，这种结构增加了安全问题的复杂性。 与 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 代码片断很不安全，因为 攻击者可以在他提交的输入中嵌入分隔命令的字符，从而达到执行危险命令的目的： 如果 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 message = message.replace (“,_); message = message.replace (,_); message = message.replace (%,_); message = message.replace (;,_); message = message.replace (,_); message = message.replace (),_); message = message.replace ( message = message.replace (+,_); %你提交的消息是： 由于要列举出所有不合法的字符比较困难，所以更安全的方法是进行正向过滤，即除了那些确实允许出现 的字符之外（例如A-Za-z0-9） ，丢弃（或者转换）所有其他字符。 八、关于 JavaBean 的说明 JSP 按照 JavaBean 规范描述的一系列约定，在 JSP 页面中快速、方便地访问可重用的组件（Java 对象） 。每个 JavaBean 组件封装了一些可以不依赖于调用环境而独伟创电脑维修立使用的数据和功能。Bean 包含数据成员（属性） ，并通过 Get 和 Set 方法实现访问这些属性的标准 API。 为快速初始化指定 Bean 的所有属性，JSP 提供了一种快捷方式，即在查询字符串中提供 name=value 对，并让它匹配目标属性的名字。考虑下面这个使用 Bean 的例子（以 XML 格式显示）： 你的购物篮 你已经把商品： 加入到购 物篮 金额是$ 准备 付款 注意在 setProperty 方法调用中使用的通配符号“*” 。这个符号指示 JSP 设置查询字符串中指定的所有 属性的值。按照本意，这个脚本的调用方式如下： http:/server/addToBasket.jsp?newItem=ITEM0105342 正常情况下，HTML 表单构造的查询字符串就是这种形式。但问题在于，没有任何东西能够防止用户设置 balance 属性： http:/server/addToBasket.jsp? newItem=ITEM0105342&balance=0 处理页面的 标记时，JSP 容器会把这个参数映射到 Bean 中具有同样名字的 balance 属性，并尝试把该属性设置为 0。 为避免出现这种问题，JSP 开发者必须在 Bean 的 Set 和 Get 方法中实现某种安全措施（Bean 必须对 属性进行强制的访问控制） ，同时，在使用 的通配符时也应该小心谨慎。 九、实现上的漏洞与源代码安全 无论是哪一种 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 实现都带有示范脚本，这些示范脚