当应用程序发送给浏览器的页面中包含用户提交的数据，
但没有经过适当验证或转义时，就会导致跨站脚本漏洞
跨站脚本的重点不在“跨站”上，而应该在“脚本”上...
因为这个“跨”实际上属于浏览器的特性，而不是缺陷
造成“跨”的假象是因为绝大多数的 XSS 攻击都会采用嵌入一段远程或者说第三方域上的脚本资源。
当攻击者的服务器上的 js 嵌入到受害者的页面，至于接下来的攻击就是关于“脚本”的事了
分类：
反射型(非持久型)：
出现在搜索栏，用户登录等地方，常用来窃取客户端的Cookie或进行钓鱼欺骗。(需要用户去点击)
存储型(持久型)：
出现在留言、评论、博客日志等交互处，直接影响Web服务器自身安全
DOM型：
是基于文档对象模型(Document Objeet Model,DOM)的一种漏洞
dom – xss是通过url传入参数去控制触发的。
一个简单的例子：
<html>
...
<script>
vara=document.URL;
document.write(a.substring(a.indexOf("a=")+2,a.length));
script>
...
html>
把上边的例子保存为test.html
浏览器访问：
http://127.0.0.1/test.html#a=
当浏览器收到源代码时便把 HTML 文本解析成 DOM 对象并执行，弹出 /xss/ 消息框
推荐阅读： 记一次从DOM型XSS到RCE过程
危害：
攻击者能够在受害者浏览器中执行脚本
迫害网站、插入恶意内容、重定向用户、组建僵尸网络、使用恶意软件劫持用户浏览器等
劫持用户会话(窃取Cookie)
网页挂马
钓鱼攻击
DoS 攻击
蠕虫攻击
劫持用户 web 行为
结合 CSRF 进行针对性攻击
防范：
前端：
用js写过滤函数，过滤特殊字符
后端(在入口和出口都过滤)：
对输入和输出都编码转换
php
$get=mysql_real_escape_string(‘输入参数/输出参数’);
?>
可以自己编写过滤函数，调用也行。或者查找网上的XSS过滤函数。
过滤XSS的开源模块
http://cnodejs.org/topic/52fd908e3e37f7546a513287
利用方式
Cookie窃取
Cookie 是 Web 系统识别用户的身份和保存会话状态的主要机制
通过 Document 对象访问 Cookie
会弹出当前页面的 cookie 信息
Cookie常见属性
Domain #设置关联 Cookie 的域名
Expires #通过给定一个过期时间来创建一个持久化 Cookie
Httponly #用于避免 Cookie 被 Javascript 访问
Name #Cookie 的名称
Path #关联到 Cookie 的路径，默认为'/'
Value #读写 Cookie 的值
Secure #用于指定 Cookie 需要通过安全 Socket 层传递连接
Cookie分类
本地 Cookie————即储存在计算机硬盘中，关闭浏览器后依旧存在
内存 Cookie————即储存在内存中，随浏览器的关闭而消失
如果设置了expires属性即为本地Cookie
默认-没设置属性的Cookie窃取
``
如果我可以将这段代码插入到某个登陆用户的页面
则Cookie就会通过HTTP请求发送给我，然后我就可以伪造那个可怜的登陆用户了
不同域-设置了domain字段
一个 Cookie 如果不知道 domain 的值，则默认为本域
例如有两个网站www.a.com和test.a.com且后者存在 xss 漏洞
按照同源策略，这两个网站是不同源的，默认情况下无法直接从test.a.com获取到www.a.com的 Cookie
可是如果www.a.com的 Cookie 值中的 domain 属性设置为父级域 即a.com
就可以通过test.a.com的 xss 漏洞获取到www.a.com的 Cookie值
不同路径-设置了path字段
在设置 Cookie 时，如果不指定 path 的值，默认就是目标页面的路径
javascript 可以指定任意路径的 cookie，但是只有对于 path 值的目录下才能读取 Cookie
Http-only
HttpOnly 是指仅在 Http 层面上传输的 Cookie
当设置了 HttpOnly 标志后，客户端脚本就无法读取该 Cookie
这样做能有效防御 XSS 攻击获取 Cookie，也是目前防御 XSS 的主流手段之一，但这只能缓解XSS之痛
利用某些特定方式也可以同样读取到标志了 HttpOnly 的 Cookie
利用调试信息，如：PHP 的 phpinfo() 和 Django 的调试信息，里边都记录了 Cookie 的值
且标志了HttpOnly 的 Cookie 也同样可以获取到。
利用 Apache Http Server 400 错误暴露 HttpOnly Cookie 的特点
Secure
设置了 Secure 的 Cookie 仅在 HTTPS 层面上进行安全传输
如果请求是 HTTP 的，则不会带上改 Cookie，这样做的好处是可以降低 Cookie 对中间人攻击获取的风险
不过对我们此处讨论的 XSS 攻击无拦截效果，可通过默认情况下获取
会话劫持--Session
由于 Cookie 的不安全性，开发者们开始使用一些更为安全的认证方式 —> Session
Session 的中文意思是会话，其实就是访问者从到达特定主页到离开的那段时间
在这个过程中，每个访问者都会得到一个单独的 Session
Session 是给予访问的进程，记录了一个访问的开始到结束
搭档浏览器或进程关闭之后，Session 也就“消失”了。
在 Session 机制中，客户端和服务端也有被其他人利用的可能。
Session 和 Cookie 最大的区别在于：
Session 是保存在服务端的内存里面，而 Cookie 保存于浏览器或客户端文件里面
我们在现实情况中可能会出现已经获取到了 Cookie
但是由于用户已经退出了浏览器指示 Session 无效，导致我们无法通过 Cookie 欺骗来获取用户权限
又比如有的网站设置了 HttpOnly，获取不到 Cookie
再者有的网站将 Cookie 与客户端 IP 向绑定，此时我们便可以利用会话劫持来达到目的
会话劫持的实质就是模拟 GET/POST 请求(带 Cookie)通过受害者浏览器发送给服务器
我们可以通过下面的方式来完成
通过 javascript 控制 DOM 对象来发起一个 GET 请求：
var img=document.creatElement("img");
img.src="http://www.a.com/del.php?id=1";
document.body.appendChild(img);
通过 javascript 自动构造隐藏表单并提交 (POST)
通过 XMLHttpRequest 直接发送一个 POST 请求
我们可以通过构造的 GET/POST 请求来实现如添加管理员、删除文章、上传文件等操作
XSS 蠕虫从某种意义上来说也属于会话劫持
钓鱼
现在一般我们都可以很容易的防范钓鱼网站，可是当钓鱼网站与 XSS 漏洞结合呢？
如 mail.qq.com 的页面存在 XSS 漏洞，攻击者通过 iframe 替换了原来的页面成钓鱼页面
并且网页的 Url 还是原来的页面，你是否能察觉出来？
XSS 重定向钓鱼
即从www.a.com通过 xss 漏洞跳转到www.b.com的钓鱼页面上，整个过程变化明显，受害者易察觉
http://www.a.com/index.php?search=<script>document.location.href="http://www.b.com/index.php"script>
HTML 注入式钓鱼
通过 javascript 来修改页面的 DOM 对象属性
Iframe
攻击者通过 javascript 来添加一个新的