一、XSS简介
XSS全称（Cross Site Scripting）跨站脚本攻击，为了避免和CSS层叠样式表名称冲突，所以改为了XSS，是最常见的Web应用程序安全漏洞之一，位于OWASP top 10 2013/2017年度分别为第三名和第七名，XSS是指攻击者在网页中嵌入客户端脚本，通常是JavaScript编写的危险代码，当用户使用浏览器浏览网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的。
OWASP（开放式Web应用程序安全项目）是一个开放的社区，由非营利组织 OWASP基金会支持的项目。对所有致力于改进应用程序安全的人士开放，旨在提高对应用程序安全性的认识。其最具权威的就是"10项最严重的Web 应用程序安全风险列表"，总结并更新Web应用程序中最可能、最常见、最危险的十大漏洞，是开发、测试、服务、咨询人员应知应会的知识。
2021 OWASP Top 10榜单及变化A01：访问控制失效（Broken Access Control）从第五位上升到了第一位。94%的应用程序都经过了某种形式的访问控制失效测试。映射到访问控制失效的34个CWE在应用程序中的出现频率比其他任何类别都要多。
A02：2021年，加密失败（Cryptographic Failure）------此前名为"敏感数据暴露"（Sensitive DataExposure），这一名称只是描述了广泛的症状而非根本原因------上移到了榜单第二位。此处需要重新关注与密码学相关的故障，这些故障通常会导致敏感数据暴露或系统受损。
A03：2021年，注入（Injection）下滑到第三位。94%的应用程序都测试了某种形式的注入，注入类别中如今包括跨站脚本。映射到该类别的33个CWE在应用程序中出现次数第二多。
A04：不安全设计（Insecure Design）是2021年出现的新类别，并且一出场就高居第四位。此处需要重点关注与设计缺陷相关的风险。如果我们真的想作为一个行业"左移"，就需要更多地使用威胁建模、安全设计模式和原则以及参考架构。
A05：2021年，安全配置错误（Security Misconfiguration）从上一版的第6位上升到了第5位。90%的应用程序都经过了某种形式的错误配置测试，随着转向高度可配置软件的趋势不可逆，看到这一类别排名上升也就不足为奇了。此前版本的XML外部实体注入（XXE）类别现在也被合并为该类别的一部分。
A06：2021年，脆弱过时组件（Vulnerable and Outdated Component）------此前名为"使用具有已知漏洞的组件"（Using Components with Known Vulnerabilities）------也从第6位一跃进入第6位。该类别是唯一一个没有任何CVE映射到所含CWE的类别，因此默认的漏洞与影响权重计5.0分。
A07：2021年，识别与认证失败（Identification and Authentication Failure）------此前称为"身份验证失效"（Broken Authentication）------排名从此前的第2位降到了第7位，而且该类别目前包含更多与识别失败相关的CWE。虽然该类别仍然位列Top 10榜单，但标准化框架的可用性增加似乎有助于解决这一问题。
A08：软件和数据完整性故障（Software and Data Integrity Failure）是2021年新增的一个类别，主要关注缺乏完整性验证情况下做出与软件更新、关键数据和持续集成/持续交付（CI/CD）流水线相关的各种假设。CVE/CVSS数据最高加权影响之一映射到该类别中的10个CWE。此前版本中的"不安全反序列化"（Insecure Deserialization）类别如今也被归入这一更大类别。
A09：2021年，安全日志与监测失败（Security Logging and Monitoring Failure）------此前名为"日志记录和监控不足"（Insufficient Logging & Monitoring）------从最后一名上升至第9位。而且该类别已扩展纳入了其他类型的故障，虽然这些故障难以测试，并且在CVE/CVSS 数据中没有得到很好的体现，但却会直接影响可见性、事件警报和取证。
A10：排在最后一位的服务器端请求伪造（Server-Side Request Forgery）是2021年新增的类别。虽然数据显示其发生率相对较低，但测试覆盖率却高于平均水平，并且漏洞利用和影响潜力的评级也高于平均水平。该类别是行业安全专家为我们预警的一种重要场景，尽管目前并没有数据能够证实其危险性。
从上面中的一段话，可以得知，XSS属于客户端攻击，受害者最终是用户，但特别要注意的是网站管理人员也属于用户之一。这就意味着XSS可以进行"服务端"攻击，因为管理员要比普通用户的权限大得多，一般管理员都可以对网站进行文件管理，数据管理等操作，而攻击者一般也是靠管理员身份作为"跳板"进行实施攻击。
XSS攻击最终目的是在网页中嵌入客户端恶意脚本代码，最常用的攻击代码是javascript语言，但也会使用其它的脚本语言，例如：ActionScript、VBscript。而如今的互联网客户端脚本基本是基于Javascript,所以如果想要深入研究XSS，必须要精通Javascript。
二、XSS出现原因
程序对输入输出的控制不够严格，导致"精心构造"的脚本输入后，在输出到前段时被浏览器当作有效代码解析执行从而产生危害。
三、XSS的危害
1、首先对于那些半年没有更新的小企业网站来说，发生XSS漏洞几乎没有什么用。一般在各类的社交平台，邮件系统，开源流行的Web应用，BBS，微博等场景中，造成的杀伤力却十分强大。
2、劫持用户cookie是最常见的跨站攻击形式，通过在网页中写入并执行脚本执行文件（多数情况下是JavaScript脚本代码），劫持用户浏览器，将用户当前使用的sessionID信息发送至攻击者控制的网站或服务器中。
3、"框架钓鱼"。利用JS脚本的基本功能之一：操作网页中的DOM树结构和内容，在网页中通过JS脚本，生成虚假的页面，欺骗用户执行操作，而用户所有的输入内容都会被发送到攻击者的服务器上。
4、挂马（水坑攻击）
5、有局限性的键盘记录
四、XSS的分类
1、反射型
与服务端交互，但是交互的数据一般不会被存在数据库中，一次性，所见即所得，一般出现在查询类页面等。
2、存储型
交互的数据会被存在数据库中，永久性存储，一般出现在留言板，注册等页面。
3、DOM型
不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的漏洞，大部分属于反射型，少部分属于存储型。
五、分类详细介绍
1、反射型XSS或不持久型XSS（中低危）
交互的数据一般不会存在数据库里，只是单纯的把用户输入的数据反射给浏览器，一次性，所见即所得。
<?php
name = _GET['name'];
echo "Welcome $name<br>";
?>
示例：比如将上面的代码放到一个文件中，比如文件名称为xss.php，然后将文件放入到phpstudy的网站目录中去
访问一下看看效果， http://192.168.0.15/xss.php?name=1 ，这个代码很明显没有数据库注入漏
洞，但是存在xss漏洞，因为这段代码并没有对用户的参数数据进行过滤处理。
攻击方法'"><script>confirm(1)</script> ，其中'"> 我们称之为完成闭合符号，后面跟script标签
来进行攻击，弹出了窗口表示我们的js代码被执行了。
并且这种弹框的代码是没有什么太大的攻击性的，所以可以作为进行xss的漏洞测试。其实对于初级挖洞的人来说，这个代码就够了，但是如果作为攻防中的红方的话，你还需要往下学习更多的手段。
其实xss的代码手段非常多，因为别人可能通过过滤等手段对script标签做了限制，那么你想攻击的话，就要改变方式，所以攻击代码的写法非常多。
效果：出现了弹框，表示此处有XSS漏洞。
2、存储型XSS或持久型XSS（高危）
交互的数据会被存在在数据库里面,永久性存储,具有很强的稳定性。
示例： '"><script>confirm(1)</script>
效果：访问页面后出现弹框，说明这个攻击代码存储到了数据库，每次刷新的时候，都会加载这个数据，执行输入的js代码，所以存储型漏洞很严重。
3、DOM XSS（中低危）
通过前端的dom节点形成的XSS漏洞，一般不与后台服务器产生数据交互，属于中低危漏洞了。
DOM全称是Document Object Model，也就是文档对象模型。我们可以将DOM理解为，一个与系统平台和编程语言无关的接口，程序和脚本可以通过这个接口动态地访问和修改文档内容、结构和样式。当创建好一个页面并加载到浏览器时，DOM就悄然而生，它会把网页文档转换为一个文档对象，主要功能是处理网页内容。故可以使用 Javascript 语言来操作DOM以达到网页的目的。
dom型xss的产生原因是由于前端js代码的DOM操作导致。
可能触发DOM型XSS的js操作：
document.referer
location
innerHTML
document.write
闭合标签：
' onclick="alert(1111)"
' onclick="alert('xss')">
'><img src="#" onmouseover="alert('xss')">
<a href="'</a><script>alert(1);</script>">what do you see?</a>
点击a标签提示文字，效果如下：
4、XSS可能存在的地方
其实只要是有用户输入输出、用户交互等一些地方，都可能存在xss漏洞。
参考xss跨站脚本攻击文档
HTML context
Attribute Context
URL Context
Style Context
5、XSS测试方法
1、工具扫描：APPscan、AWVS、xray等大型漏扫工具、xsstrike等自动化小工具。
https://github.com/s0md3v/XSStrike
2、手工测试：Burpsuite、firefox(hackbar)、360开发的一款浏览器插件
使用手工检测Web应用程序是否存在XSS漏洞时，最重要的是考虑哪里有输入，输入的数据在什么地方输出。在进行手工检测XSS时，人毕竟不像软件那样不知疲惫，所以一定要选择有特殊意义的字符，这样可以快速测试是否存在XSS。
（1）在目标站点上找到输入点,比如查询接口,留言板等;
（2）输入一组"特殊字符+唯一识别字符",点击提交后,查看返回的源码,是否有做对应的处理;
（3）通过搜索定位到唯一字符,结合唯一字符前后语法确认是否可以构造执行js的条件(构造闭合);提交构造的脚本代码,看是否可以成功执行,如果成功执行则说明存在XSS漏洞。