http://sdh5724.javaeye.com/blog/266330

1. SQL Injection<SQL注入攻击>
在Java中， 使用PrepareStatment是不可能产生这样的攻击的， 通常这类攻击产生是由于程序员借助一些API，或者配置文件， 动态的修改SQL语句造成的。 如果程序员不对输入的参数不做检查或者转义编码， 就可能产生SQL攻击。 防范这个问题的最简单的办法是， 不要使用用户输入的参数组装SQL语句。 这可能有点凹口。 实际上这类问题通常发在类似的操作上， 使用like, order by等操作上。 这2个语句最容易产生SQL注入：
select * from table_a where table_a.col like '%$name$%'
如果用户输入： ';select * from sys
组装完SQL后， 变成了
select * from table_a where table_a.col like '%';select * from sys%'
所以， 后面的东西变成什么恶意的SQL， 那么问题就来了。 如果是DDL语句，后果自己想。
例子很多的， 但是， 一个原则， 不要动态的手动组装SQL语句。
2. XSS攻击<跨站脚本>： 攻击者在页面中注入具有恶意js或者html代码，从而完全控制用户浏览器。如果你的web应用必须支持用户提供的HTML，那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护web站点：确认你接收的HTML内容被妥善地格式化，仅包含最小化的、安全的tag（绝对没有JavaScript），去掉任何对远程内容的引用（尤其是样式表和JavaScript）。
对于非HTML的输出， 必须使用HTML ESCAPED来转义输出内容。

3.安全控制
在很多网站上， 有很多UPDATE、 DELETE、INSERT的操作， 但是， 由于程序员的忽略， 这些操作没有限制用户操作权限。
比如 http://sdh5724.iteye.com/admin/blogs/deleteblog?id=12345
SQL 写成了 delete from blog where id=12345
那么有用户把12345 修改为 54321就可能删除别人的文章了。 这个安全因素在非常的网站都存在。从授权角度来来说， 这个SQL写成 delete from blog where id=12345 and memberid='sdh5724' 这样就安全了。
这个问题的变形是很多的。 开发的时候需要注意。

4. CSRF攻击,伪造客户端请求的一种攻击，CSRF的英文全称是Cross Site Request Forgery，字面上的意思是跨站点伪造请求
主要如下:
1． 没有验证用户http请求的方式 POST 或者 GET，GET请求被合法通过!
2． 没有验证表单来源的唯一性，不能识别是合法的表单提交还是黑客伪造的表单提交!
这个问题主要是要防止构造一个FORM表单提交，通过为FORM表单增加一个检查字段<session token>. 提交的时候， 确定该session token是否是该用户生产的。 session token可以保存在cache,数据库， 或者sesion中。

大约目前Web攻击就这些类型， 但是都是非常复杂的。 需要仔细的研究才能明白。说的解决办法都是简易的。 如果要一个完全的解决办法，最好咨询安全工程师或者小黑们。