五、输入检验 从安全的角度来看，输入检验包括对来自外部数据源（非置信数据源，参见前面说明）的数据进行语法检查，有时还要进行语义检查。依赖于应用的关键程度和其他因素，作为输入检验结果而采取的动作可能是下面的一种或者多种： · 忽略语法上不安全的成分， · 用安全的代码替换不安全的部分， · 中止使用受影响的代码， · 报告错误， · 激活一个入侵监测系统。 输入检验可以按照以下两种模式之一进行：列举不安全的字符并拒绝它们；定义一组安全的字符，然后排除和拒绝不安全的字符。这两种模式分别称为正向和反向输入过滤。一般地，正向输入过滤更简单和安全一些，因为许多时候，要列举出服务器端应用、客户端浏览器、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脚本中常常出现的代码和配置级安全问题，提出了降低由此带来的安全风险的建议。
五、输入检验 从安全的角度来看，输入检验包括对来自外部数据源（非置信数据源，参见前面说明）的数据进行语法检查，有时还要进行语义检查。依赖于应用的关键程度和其他因素，作为输入检验结果而采取的动作可能是下面的一种或者多种： · 忽略语法上不安全的成分， · 用安全的代码替换不安全的部分， · 中止使用受影响的代码， · 报告错误， · 激活一个入侵监测系统。 输入检验可以按照以下两种模式之一进行：列举不安全的字符并拒绝它们；定义一组安全的字符，然后排除和拒绝不安全的字符。这两种模式分别称为正向和反向输入过滤。一般地，正向输入过滤更简单和安全一些，因为许多时候，要列举出服务器端应用、客户端浏览器、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脚本中常常出现的代码和配置级安全问题，提出了降低由此带来的安全风险的建议。
getRemoteUser
isUserInRole
getUserPrincipal getRemoteUser方法返回经过客户端验证的用户名。IsUserInRole向container的安全机制询问一个特定的用户是否在一个给定的安全角色中。GetUserPrinciple方法返回一个Java.security.Pricipal对象。这些APIs根据远程用户的逻辑角色让servlet去完成一些逻辑判断。它也可以让servlet去决定当前用户的主要名字。如果getRemoteUser返回null值（这意味着没有用户被验证），那么isUserInRole就总会返回false，getUserPrinciple总会返回null。 三 、Roles 一个Roles就是由Application Developer和Assembler所定义的一个抽象的逻辑用户组。当一个application被发布的时候，Deployer就把这些角色映射到在运行环境中的安全认证，例如组或规则。 一个servlet container能够为规则执行一些说明或编程安全，这些规则是与调用这些principal的安全属性所输入的要求相联系的。例如： 1．当deployer把一个安全角色映射为操作环境下的一个用户组，调用principle所属的用户组就从安全属性中获得。如果principle的用户组与在操作环境下的用户组相匹配，那么principle 就是一个安全角色。
2．当deployeer把一个安全角色映射为一个在安全方针域中的principle名时，调用principle的确principle名就被从安全属性中提取出来。如果两者相同的话，调用的principle就是安全的。 四、Authentication 一个web 客端能够使用下面的一种机制来对web 服务器验证一个用户。 HTTP Digest Authentication
HTTPS Client Authentication
HTTP Basic Authentication
HTTP Based Authentication 五、HTTP Basic Authentication HTTP Basic Authentication是一个定义在HTTP/1.1规范中的验证机制。这种机制是以用户名和密码为基础的。一个web server要求一个web client去验证一个用户。作为request的一部分，web server 传递被称之为realm的字符串，用户就是在它里面被验证的。注意：Basic Authentication机制的realm字符串不一定反映任何一种安全方针域。Web client得到这些用户名和密码，然后把它传递给web server。Web server然后在一个特定的领域验证这些用户。 由于密码是使用一种64位的编码来传递，而且目的server没有验证，所以Basic Authentication不是一种安全的验证协议。然而一些附加的保护像使用一种安全传输机制（HTTPS）或在网络层使用安全措施能够解决一些问题。 六、HTTP Digest Authentication 与HTTP Digest Authentication一样，HTTP Digest Authentication根据用户名和密码验证一个用户。然而密码的传输是通过一种加密的形式进行的，这就比Basic Authentication所使用的64位编码形式传递要安全的多。这种方法没有像HTTPS Client Authentication的个人密钥方案安全。由于Digest Authentication当前不被广泛使用，servlet containers不要求支持它但是鼓励去支持它。 七、HTTPS Client Authentication 使用HTTPS（HTTP over SSL）的终端用户验证是一种严格非验证机制。这种机制要求用户去处理公共密钥证明（Public Key Certification PKC）。当前，PKCs在e-commerce应用中是有用的。不适应J2EE的servlet containers不要求支持HTTPS协议。 八、Server Tracking of Authentication Information 就像映射在角色中的安全标识一样，运行环境是环境的说明而不是应用的说明。 1．在web application的发布环境创建一个登录机制和策略。
2．对发布在同一个container的application能够使用同样的验证信息来代表这些application的principal。
3．仅仅当通过安全策略域时要求用户重新验证。 因此，一个servlet container要求在container层来跟踪这些验证信息，而不是在application层。允许一个经验证的用户拒绝一个使用其它资源的application，这些是通过受同样安全性标识限制的container管理的。
不好意思问个web问题：
采用的数据库是SQLSERVER
语言是java/jsp/javascript
哪位能提供连接数据库用的DB.java类啊
<%Class.forName("org.gjt.mm.mysql.Driver").newInstance(); String url ="jdbc:mysql://localhost/stu?useUnicode=true&characterEncoding=8859_1" ;//testDB为你的数据库名 Connection conn= DriverManager.getConnection(url); Statement stmt=conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE); String sql="select * from stuinfo"; ResultSet rs=stmt.executeQuery(sql); while(rs.next()) {%> 您的第一个字段内容为：<%=rs.getString(1)%> 您的第二个字段内容为：<%=rs.getString(2)%> <%}%> <%out.print("数据库操作成功，恭喜你");%> <%rs.close(); stmt.close(); conn.close(); %>
文件路径开头为 "/file/" 的漏洞、IBM WebSphere 3.0.2的"/servlet/file/"文件开头漏洞等等。 例子：如IBM WebSphere 3.0.2中，如果一个请求文件的 URL 为"login.jsp":http://site.running.websphere/login.jsp，那么访问http://site.running.websphere/servlet/file/login.jsp将看到这个文件的源代码。 原因：因为IBM WebSphere 3.0.2是调用不同的 servlets 对不同的页面进行处理，如果一个请求的文件是未进行注册管理的，WebSphere 会使用一个默认的 servlet 调用。如果文件路径以"/servlet/file/"作开头这个默认的 servlet 会被调用这个请求的文件会未被分析或编译就显示出来。 解决方法：在服务器软件的网站下载最新的补丁。 3、路径权限引起的文件jsp源代码暴露 这种漏洞在正常的jsp漏洞中没有反映出来，但是笔者在写jsp程序中曾经碰到过，头疼了一阵子，最后总算解决了。我们知道，大部分的jsp应用程序在当前目录下都会有一个WEB-INF目录，这个目录通常存放的是JavaBeans编译后的class 文件，如果不给这个目录设置正常的权限，所有的class就会曝光。 例子：笔者当时采用的是Apache1.3.12加上第三方jsp软件形式的WEB服务器，因为Apache1.3.12默认的设置是可以读取目录的，如果程序在http://site.running.websphere/login.jsp，只要修改一下http://site.running.websphere/WEB-INF/所有这个目录下以及这个目录下的子目录中的class文件可以看个一干二净的，还可以下载到本机上。 也许你会说class是经过编译的，就算被人下载也没有什么关系，但是现在class 反编译为java代码的软件也很多，笔者当时采用JAD软件对下载的class文件反编译了一下，居然和原始的java文件几乎一模一样，变量名都没有变，更惊奇的是还可以重新编译为class文件正常使用。 安全问题更大的就是，笔者开始把数据库的用户名密码都写在了java代码中，现在一反编译谁都能看到数据库的重要信息。通过数据库的远程连接功能，可以轻松的进入到你的数据库中，所有信息全部在他手中。附带说一句，如果用户能获得SQL Server的用户名口令(sa 的)，进入数据库中可以执行任意的dos命令如查看c:\文件、建立和删除目录等，那样整个Windows系统都不安全了(此种方法危害性更大，恕作者不公布出来)。 作者曾经偶然在网上看到过国内某个大型网站有同样的问题，而且密码也是和笔者一样写在JavaBean中的，极不安全。 解决方法：IIS以前一个有效地解决asp的漏洞就是将asp程序单独放置一个目录，目录设置上用户权限只能执行不能读取。在jsp环境下同样可以通过设置服务器的环境来解决这个问题，简单的说就是将一些比较重要的目录如WEB-INF、classes等设置上访问的权限，不允许读而取只允许执行。以apache 下解决为例，可以在httpd.conf文件中添加一目录WEB-INF并设置Deny from all等属性。 另一种比较笨的解决方法就是在每个重要目录下添加一个默认起始页面如inde.htm等，这样读取目录就会返回给访问者这个文件而不是其它了。建议采用的一种方法。 更为重要的是密码的保存问题，笔者以前在asp 开发中是采用密码文件保存在系统目录如WINNT 下的，然后写了一个com来读取这个文件，这样就算看到了asp源代码也不知道数据库信息了。在jsp中我们也可以写一个property文件，放置在WINNT系统目录下，然后用Bean来读取数据库信息，这样通过源代码知道了数据库信息存在WINNT中的.property文件里面，但也很难访问它，这样就算源代码被人知道起码数据库是安全的。 4、文件不存在引起的绝对路径暴露问题 这个问题相信大家都比较熟悉了，因为微软IIS 中也有比较多的类似问题如微软IIS5.0中的*.idc暴露绝对路径漏洞。同样的这些问题现在也转到了jsp环境中，这个漏洞暴露了web程序的绝对硬盘地址，和其他漏洞结合就具有比较大的危害了，因为这个漏洞目前还没有在国外安全网站上看到，而站长也没有一一测试过所有的jsp服务器程序，所以没有办法告诉大家那些有这个漏洞了，大家可以在自己的web服务器上测试看看。 例子：在特定的服务器软件下，访问一个不存在的jsp文件如 http://localhost:8080/fdasfas.jsp，就会返回java.servlet.ServletEception: java.io.FileNotFoundEception: c:\web\app\fadssad.jsp (???????????)这样的错误，这样就可以知道你网站在c:\web\app目录下，也许一般人不太在意，但是对于一个黑客来说就是很有帮助了。 原因：负责jsp 执行的相关Servlet中处理异常的时候没有过滤掉这种情况。 解决方法：一是下载最新的补丁；由于笔者当时的web 服务器软件没有这个补丁，经过一段时间的痛苦煎熬后，总算找到了另外一种方法，就是找到服务器软件的jsp 执行映射Servlet文件(当然是class 后缀的)，将它用JAD软件反编译，在反编译后的源代码中找到处理Eception的方法，然后将方法中的处理部分全部注释掉，并将请求导向到一个自定义的出错页面中，这样问题就解决了。 二、远程程序执行类 这类漏洞的特点就是可以通过url 地址在浏览器中执行任意服务器上的命令和程序，从而引起安全问题。如Allaire JRUN 2.3 远程执行任意命令漏洞、iPlanet Web Server 4.x存在一个缓冲区溢出漏洞等等。 例子：Allaire 的 JRUN 服务器 2.3上输入下面的url地址http://jrun:8000/servlet/jsp/../../path/sample.txt，可以访问到WEB目录以外的文件，如果是exe文件，还有可能会引起执行。 原因：如果URL请求的目标文件使用了前缀"/servlet/"，则JSP 解释执行功能被激活。这时在用户请求的目标文件路径中使用"../"，就有可能访问到 WEB 服务器上根目录以外的文件。目标主机上利用该漏洞请求用户输入产生的一个文件，将严重威胁到目标主机系统的安全。 解决方法：安装最新的补丁。三、其他类别 这些类别的范围就有点大了，可以包括数据库如SQL Server、Oracle 、DB2等的漏洞，也可以包括操作系统如WindowsNT/2000、Linu等的漏洞。这些东西的漏洞可以说都是致命的，如利用Linu的某些漏洞可以轻易的Su为管理员来远程控制服务器，获得系统的完全控制权限，这样要获得jsp源代码或者摧毁服务器比踩死一只蚂蚁还要轻松的多。四、全文总结 通过上面内容我们可以看出jsp同asp一样还是存在着很多安全上的问题的，客观的说，服务器软件的开发商在内部测试中不可能将系统中的所有bug 找出来，即使发布了软件后，被发现的漏洞也只会是其中的很小一部分，将来还会不断的有新的安全问题出现，所以我们必须时刻提高警惕，并注意自己网站的安全。 一个好的建议就是多看安全文章，这些安全文章一般都会有详细的信息如软件的版本号、漏洞原因等等，最重要的是还附带了解决办法或者是补丁的下载链接，推荐的安全站点是国内的安全站点www.cnns.net或者国外的www.securityfocus.com站点；另外一个好的建议就是多装补丁程序，访问自己所使用的软件公司主页，从那上面获得最新的补丁程序，做得比较好的就是微软的站点，安全公告和补丁都特别及时。 最后想用一句话作为全文的结尾：一个优秀的黑客不一定是个好的jsp 程序员，一个优秀的jsp程序员一定要是个好的准黑客。
plase