JSP应用的安全问题
服务器和操作系统可能误解的字符并不是一件容易的事情。
请参见本文下面“通过嵌入标记实现的攻击”部分中输入检验的例子，这个例子示范了如何避免误解恶意提交的输入内容。
六、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.replac
请参见本文下面“通过嵌入标记实现的攻击”部分中输入检验的例子，这个例子示范了如何避免误解恶意提交的输入内容。
六、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.replac