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
· 请求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