常见的Web攻击有SQL注入、XSS跨站脚本攻击、跨站点请求伪造共三类，下面分别简单介绍。

       SQL注入就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。SQL注入漏洞到底是以怎样的形式进行攻击的呢，接下来将以一个简单的实例来进行介绍。

       比如在一个登陆界面，有两个文本框分别用来输入用户名和密码，当用户点了登录按钮的时候，会对输入的用户名和密码进行验证。

验证的SQL语句可以简单理解为：select * from student where username=‘输入的用户名’ and password=‘输入的密码’ ，如果能够检索到数据，说明验证通过，否则验证不通过。

如果用户在用户名文本框中输入 ’ or ‘1’ = ‘1’ or ‘1’ = ‘1，则验证的SQL语句变成：select * from student where username=" or ‘1’ = ‘1’ or ‘1’ = ‘1’ and password= " 如果用户在密码文本框中输入 1 ’ or ‘1 ‘=’ 1，则验证的SQL语句变成：select * from student where username=’’ and password=‘1’ or ‘1’=‘1’ 以上两个SQL语句的where条件永远是成立的，所以验证永远是有效的。

另外，如果在用户名文本框中输入 tom’ ; drop table student- -，则SQL语句变成：

这样就变成两条SQL语句，执行完查询操作，接着直接把student表给删除了（双连接符表示注释）。

       通过上面的描述我们就很清楚的明白，黑客如果发现平台里有SQL注入漏洞，那么我们的平台就会轻而易举的被攻破了。那么我们如何写代码，才能实现对SQL注入攻击进行更好的防御呢。下面将分别介绍下防御措施：

1、永远不要信任用户的输入

对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双“-”进行转换等；具体表现如下：

①输入为数字参数则必须进行数字类型判断

如采用正则表达式：String characterPattern = “^\d+$”;

②输入为字符串参数则必须进行字符型合法性判断

如采用正则表达式：String characterPattern = ^[A-Za-z]*$;

③输入只允许包含某些特定的字符或字符的组合使用白名单进行输入校验，如email地址、日期、小数等： String characterPattern = "^([a-z0-9A-Z]+[_-]?)+[a-z0-9A-Z]@(([a-z0-9A-Z]+[_-]?)+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,4}$"; //email正则表达式

④校验输入数据的长度

⑤校验输入数据的范围，如年龄为0~50之间的正整数

⑥将特殊字符单引号和双“-”进行转换。

2、永远不要使用动态拼装sql

可以使用参数化的sql或者直接使用存储过程进行数据查询存取。哪怕参数是常量，也请用预编译语句PreparedStatement，同时用占位符，如： “select * from table where comment like ?”。

注意：如果参数不是使用的占位符，即使用PreparedStatement执行时也并不是预编译。

3、永远不要使用管理员权限的数据库连接

为每个应用使用单独的有权限的数据库连接，这样能降低数据库密码被泄漏而带来的破坏。

4、不要把机密信息直接存放

加密或者hash掉密码和敏感的信息；如数据库连接密码、用户密码、设备密码需要加密存储。

5、应用的异常信息应该给出尽可能少的提示

最好使用自定义的错误信息对原始错误信息进行包装。

       XSS(Cross Site Scripting)跨站脚本攻击指攻击者在网页中嵌入客户端脚本(例如JavaScript)，当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的，比如获取用户的Cookie，导航到恶意网站，携带木马等。XSS漏洞到底是以怎样的形式进行攻击的呢，接下来将通过两个不同的场景来进行介绍。

1、Dom-Based XSS 漏洞

基于DOM的XSS，也就是web server不参与，仅仅涉及到浏览器的XSS

攻击过程如下：小A发现了test.com中的Search.jsp页面有XSS漏洞，Search.jsp的代码如下：

没有对term做任何过滤校验。

       小A 先建立一个网站http://badboy.com，用来接收“偷”来的信息。然后小A构造一个恶意的url(如下)，通过某种方式(邮件，QQ)发给小B

       小B点击了这个URL，嵌入在URL中的恶意Javascript代码就会在小B的浏览器中执行，那么小B在test.com网站的cookie，就会被发送到badboy网站中，这样小B在test.com的信息就被小A盗了。

2、Stored XSS(存储式XSS漏洞)

       如一个应用程序从数据库中查询数据，在页面中显示出来，攻击者在这个页面输入恶意的脚本数据后，用户浏览此类页面时就可能受到攻击，使得所有访问该页面的用户都面临信息泄露的可能。

攻击过程如下：

       小C发现了网站A上有一个XSS 漏洞，该漏洞允许将攻击代码保存在数据库中，于是小C发布了一篇文章，文章中嵌入了恶意JavaScript代码。其他人如小D访问这片文章的时候，嵌入在文章中的恶意Javascript代码就会在小D的浏览器中执行，其会话cookie或者其他信息将被小C盗走。

Dom-Based XSS漏洞威胁用户个体，而存储式XSS漏洞所威胁的对象将是大量的用户。

针对XSS跨站脚本攻击，我们的防御原则是不相信用户输入的数据，对应的防御措施如下：

1、在cookie中不要存放一些敏感信息        比如用户名、密码等安全信息，或者cookie中的信息采用加密的方式。最为有效的方式是将重要的cookie标记为http only，这样脚本中就不能访问这个cookie，就避免了XSS攻击利用JavaScript的document.cookie获取cookie：

2、输入过滤校验，对用户提交的数据进行有效性验证

       仅接受指定长度范围内并符合我们期望格式的的内容提交，阻止或者忽略除此外的其他任何数据。比如：电话号码必须是数字和中划线组成，而且要设定长度上限。过滤一些些常见的敏感字符，例如：< > ‘ “ & # \；过滤或移除特殊的Html标签， 例如: , , ; for , for；过滤JavaScript 事件的标签，例如 "οnclick=", "onfocus" 等等。这里的数据校验除了前台要做，后台也要做。

3、DOM型的XSS攻击防御 　　把变量输出到页面时要做好相关的编码转义工作，如要输出到 中，可以进行JS编码；要输出到HTML内容或属性，则进行HTML编码处理。根据不同的语境采用不同的编码处理方式。

       CSRF（ Cross-site request forgery ）尽管听起来很像XSS跨站脚本攻击，但是它于XSS完全不同。XSS是利用站点内的信任用户，而CSRF则是通过伪装来自受信任用户的请求来利用受信任的站点，从而在并未授权的情况下执行在权限保护之下的操作。与XSS相比，CSRF攻击不大流行和难以防范，所以比XSS更具危险性。 从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤 ： 1.登录受信任网站A，并在本地生成Cookie 。 2.在不退出A的情况下，访问危险网站B。

接下来通过实例来介绍什么是CSRF攻击

       受害者 tom 在银行有一笔存款，通过对银行的网站发送请求：http://bank.example/withdrawaccount=tom&amount=1000000&for=tom2 可以使 tom把 1000000 的存款转到 tom2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 tom 已经成功登陆。

       黑客 tom3 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。 tom3 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=tom3 。但是这个请求来自tom3 而非tom ，他不能通过安全认证，因此该请求不会起作用。

       这时，tom3 想到使用CSRF的攻击方式，他先自己做一个网站，在网站中放入如下代码：