关于JSP的安全问题，请谈谈

这P文章你参考一下：（我收藏的，不错）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规范允许几乎所有其他语言扮演这个角色。这样，这些替代语言的安全问题也必须加以考虑。
非置信的用户输入（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服务器具有访问权限）。 进行适当的输入检验可以防止这类问题出现。 
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>的通配符时也应该小心谨慎。