XSS攻击的类型
XSS攻击分成两类
一类是来自内部的攻击，主要指的是利用程序自身的漏洞，构造跨站语句
另一类则是来自外部的攻击，主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页
如当我们要渗透一个站点，我们自己构造一个有跨站漏洞的网页，然后构造跨站语句，通过结合其它技术
如社会工程学等，欺骗目标服务器的管理员打开
反射型XSS
反射型XSS是非持久性、参数型的跨站脚本
反射型XSS的JS代码在Web应用的参数(变量)中，如搜索框的反射型XSS
在搜索框中，提交
PoC[<script>alert(/xss/)</script>]
点击搜索，即可出发反射型XSS
注意到，我们提交的poc会出现在search.php页面中的keywords参数中
当今的网站中包含大量的动态内容以提高用户体验，比过去要复杂得多
所谓动态内容，就是根据用户环境和需要，Web应用程序能够输出相应的内容
动态站点会受到一种名为“跨站脚本攻击”
(Cross Site Scripting 安全专家们通常将其缩写成XSS
原本应当是css,但为了和层叠样式表(Cascading Style Sheet,CSS)有所区分，故称XSS)
的威胁，而静态站点则完全不受其影响。
用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时，通常会点击其中的链接
攻击者通过在链接中插入恶意代码，就能够盗取用户信息
攻击者通常会用十六进制（或其他编码方式）将链接编码，以免用户怀疑它的合法性
网站在接收到包含恶意代码的请求之后会产成一个包含恶意代码的页面
而这个页面看起来就像是那个网站应当生成的合法页面一样
许多流行的留言本和论坛程序允许用户发表包含HTML和javascript的帖子
假设用户甲发表了一篇包含恶意脚本的帖子，那么用户乙在浏览这篇帖子时，恶意脚本就会执行，盗取用户乙的session信息
有关攻击方法的详细情况将在下面阐述。
利用此漏洞，还可以实现一种攻击叫做CSRF，CSRF（Cross-site request forgery）跨站请求伪造
也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用
尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左
XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站
与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
也就是说，黑客如果向论坛中注入如下代码：
<script>
document.location="http://shopping.taobao.com/ShoppingProcess.php?goods=cpu&quantity=1000";
</script>
加入论坛的用户同时也是网站http://shopping.taobao.com/的合法用户，其客户端登录http://shopping.taobao.com/网站后具有该网站的
Cookie如果这时该用户打开论坛，显示论坛内容时候，则执行了这段代码，于是在购物网站时结账时，账面上多扣除了1000枚CPU的价格
存储型XSS
存储型XSS：存储型XSS，持久化，代码是存储在服务器中的
如在个人信息或发表文章等地方，加入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中
用户访问该页面的时候触发代码执行。
这种XSS比较危险，容易造成蠕虫，盗窃cookie（虽然还有种DOM型XSS，但是也还是包括在存储型XSS内）
DOM XSS比较特殊。owasp关于DOM型号XSS的定义是基于DOM的XSS是一种XSS攻击
其中攻击的payload由于修改受害者浏览器页面的DOM树而执行的
其特殊的地方就是payload比较难以检测
如下面的例子：
[#message=<script>alert(/xss/)</script>]
我们以描点的方式提交PoC
PoC并不会发送给服务器，但是已经触发了XSS
查看提交参数后的HTML页面(DOM树)，会形成鲜明的对比
#应对方法
在Web 应用开发中，开发者最大的失误往往是无条件地信任用户输入
假定用户（即使是恶意用户）总是受到浏览器的限制，总是通过浏览器和服务器交互
从而打开了攻击Web应用的大门。实际上，黑客们攻击和操作Web网站的工具很多，根本不必局限于浏览器
从最低级的字符模式的原始界面（例如telnet）
到 CGI脚本扫描器、Web代理、Web应用扫描器，恶意用户可能采用的攻击模式和手段很多。
因此，只有严密地验证用户输入的合法性，才能有效地抵抗黑客的攻击
应用程序可以用多种方法（甚至是验证范围重叠的方法）执行验证
例如:在认可用户输入之前执行验证,确保用户输入只包含合法的字符,而且所有输入域的内容长度都没有超过范围
（以防范可能出现的缓冲区溢出攻击），在此基础上再执行其他验证，确保用户输入的数据不仅合法，而且合理
必要时不仅可以采取强制性的长度限制策略，而且还可以对输入内容按照明确定义的特征集执行验证
下面几点建议将帮助你正确验证用户输入数据：
⑴ 始终对所有的用户输入执行验证，且验证必须在一个可靠的平台上进行，应当在应用的多个层上进行。
⑵ 除了输入、输出功能必需的数据之外，不要允许其他任何内容。
⑶ 设立“信任代码基地”，允许数据进入信任环境之前执行彻底的验证。
⑷ 登录数据之前先检查数据类型。
⑸ 详尽地定义每一种数据格式，例如缓冲区长度、整数类型等。
⑹ 严格定义合法的用户请求，拒绝所有其他请求。
⑺ 测试数据是否满足合法的条件，而不是测试不合法的条件。这是因为数据不合法的情况很多，难以详尽列举。
