超详细XSS跨站脚本漏洞总结

1、免责声明

本公众号提供的工具、教程、学习路线、精品文章均为原创或互联网收集，旨在提高网络安全技术水平为目的，只做技术研究，谨遵守国家相关法律法规，请勿用于违法用途

2、内容速览

简单来说就是程序对输入输出没有做合适的处理，导致攻击者构造的字符输出到前端时被浏览器执行当作有效代码解析执行从而产生危害

不会存在数据库里面，一般出现在查询页面 反射型XSS，又称非持久型XSS，攻击相对于受害者而言是一次性的 具体表现在受害者点击了含有的恶意JavaScript脚本的url，恶意代码并没有保存在目标网站，而Web应用程序只是不加处理的把该恶意脚本“反射”回受害者的浏览器而使受害者的浏览器执行相应的脚本

存在数据库里面，一般出现在注册页、留言板等 存储型XSS是指应用程序通过Web请求获取不可信赖的数据，在未检验数据是否存在XSS代码的情况下，便将其存入数据库 当下一次从数据库中获取该数据时程序也未对其进行过滤，页面再次执行XSS代码持续攻击用户。 存储型XSS漏洞大多出现在留言板、评论区，用户提交了包含XSS代码的留言到数据库，当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来

不与后台服务器交互数据 也属于反射型的一种 一种通过dom操作前端输出的时候产生问题 DOM，全称Document Object Model，是一个平台和语言都中立的接口 可以使程序和脚本能够动态访问和更新文档的内容、结构以及样式 DOM-XSS简单理解就是不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题。

反射型XSS的被攻击对象一般是攻击者去寻找的 存储型XSS是广撒网的方式或者指定的方式，危害性更大，范围更广 DOM型XSS的被攻击对象其实和反射型XSS被攻击对象差不多，就是给攻击对象放送URL。

个人感觉是反射型与存储型区别的本质 反射型XSS的脚本被解析的地方是浏览器 存储型XSS的脚本被解析的地方是服务器 DOM型XSS也是浏览器，但是反射型XSS需要联网，而DOM型不需要

反射型XSS是一次性 存储型XSS是存储在服务器上，只要服务器不挂机或者是被干掉，就一直会有

这是DOM型与其他两种的区别 反射型XSS在搜索框啊，或者是页面跳转啊这些地方 存储型XSS一般是留言，或者用户存储的地方 DOM是在DOM位置上，不取决于输入环境上

在黑盒测试中，这种类型比较容易通过漏洞扫描器直接发现，我们只需要按照扫描结果进行相应的验证就可以了。

相对的在白盒审计中， 我们首先要寻找带参数的输出函数，接下来通过输出内容回溯到输入参数，观察是否过滤即可。 无案例不足以求真，这里我们选用echo()函数作为实例来分析：

新建 XssReflex.php，代码如下:

这是一个很简单、也很常见的页面： 变量 $XssReflex 获取 get 方式传递的变量名为 input 的变量值（值为一个字符串），然后直接通过echo()函数输出，注意这中间并未对用户输入进行任何过滤。

打开Firefox输入url：localhost/codeaudit/xss/XssReflex.php :

当我们输入 1 ，页面返回 1 :

当我们输入hello时，页面返回 hello :

以上都为正常的输出，但如果我们输出一些javascript代码呢？

比如我们输入alert('xss') ：

可以看到浏览器成功弹窗，说明我们输出的JavaScript代码成功被执行了。 我们查看网页html代码：

第12行增加了：

这个弹窗并没有什么实际的意义，但通过它我们知道输入javascript代码是可以被执行的，当我们输入一些其他函数，比如document.cookie就可以成功盗取用户的cookie信息，或者读取用户浏览器信息等，为我们进一步深入攻击做铺垫。

和反射性XSS的即时响应相比，存储型XSS则需要先把利用代码保存在比如数据库或文件中，当web程序读取利用代码时再输出在页面上执行利用代码。但存储型XSS不用考虑绕过浏览器的过滤问题，屏蔽性也要好很多。 存储型XSS攻击流程：

存储型XSS的白盒审计同样要寻找未过滤的输入点和未过滤的输出函数。

使用cat命令查看 XssStorage.php 代码

代码如下:

页面功能简述：

这个页面采用POST提交数据，生成、读取文本模拟数据库，提交数据之后页面会将数据写入sql.txt，再打开页面时会读取sql.txt中内容并显示在网页上，实现了存储型xss攻击模拟。

打开Firefox输入url：localhost/codeaudit/xss/XssStorage.php :

我们随意输出一些内容：

可以看到页面正常显示页面留言信息。 当我们在Message中输入alert('xss')时，页面成功弹窗 :

并且我们重启浏览器之后再加载该页面，页面依然会弹窗,这是因为恶意代码已经写入数据库中，每当有人访问该页面时，恶意代码就会被加载执行！

我们查看网页html代码：

这就是所谓的存储型XSS漏洞，一次提交之后，每当有用户访问这个页面都会受到XSS攻击，危害巨大。

①黑客在目标服务器上构造XSS恶意脚本，保存在数据库中 ②用户在网站登录状态下，访问了目标服务器，查看了存在恶意脚本的页面 ③网站将XSS同正常页面返回到用户浏览器 ④用户浏览器解析了网页中的XSS恶意代码，向恶意服务器发起请求 ⑤黑客从自己搭建的恶意服务器中获取用户提交的信息

①发送带有XSS恶意脚本的链接 ②用户点击了恶意链接，访问了目标服务器 ③网站将XSS同正常页面返回到用户浏览器 ④用户浏览器解析了网页中的XSS恶意代码，向恶意服务器发起请求 ⑤黑客从自己搭建的恶意服务器中获取用户提交的信息

可用basic认证实现钓鱼场景 在实际的攻击场景当中，xss钓鱼的场景非常多 可以内嵌一些钓鱼页面，或者钓鱼链接，basic认证等实现钓鱼

1、对任何用户的输入与输出都采取不信任

2、对特殊符号及特殊语句进行的严格过滤

3、设置黑名单与白名单

4、在开发时开发人员严格设置WEB安全编码规范

5、对cookie进行特殊防御

6、对进行网页编码实体化

7、对Session标记、验证码或者HTTP头的检查

具体如下：

A.PHP直接输出html的，可以采用以下的方法进行过滤：

B.PHP输出到JS代码中，或者开发Json API的，则需要前端在JS中进行过滤：

C.其它的通用的补充性防御手段

也就是说我们输入的字符并不会在前端输出 只有他的管理员才能看到我们输入的内容 前端用户是看不到的 如果说管理员登陆后台之后 后台界面会把输入的内容进行输出的话 就意味着后台的管理人员会被x到 那么这种场景的xss就叫xss的盲打

当协议、主机（主域名，子域名）、端口号中任意一个不同就是不同域 不同域之间请求数据的操作，称为跨域操作

同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。 可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。 两个域名之间不能使用js相互操作（更安全）

当一个浏览器的两个tab页中分别打开来 百度和谷歌的页面 当浏览器的百度tab页执行一个脚本的时候会检查这个脚本是属于哪个页面的， 即检查是否同源，只有和百度同源的脚本才会被执行 如果非同源，那么在请求数据时，浏览器会在控制台中报一个异常，提示拒绝访问。 同源策略是浏览器的行为，是为了保护本地数据不被JavaScript代码获取回来的数据污染，因此拦截的是客户端发出的请求回来的数据接收，即请求发送了，服务器响应了，但是无法被浏览器接收

利用xss盗取cookie也比较常见 ，流程主要如下：