记一次把不予解决的XSS变成高危的过程

最近发现公司业务平台存在大量的存储型XSS，有些甚至可以穿到后台直接拿管理员的cookie。
为了提高漏洞修复效率，我把这些漏洞分为了三个修复优先级提供给开发组参考：

1. 影响后台
2. 影响其他用户
3. 影响自身

然后可气又可笑的事情发生了。

有个产品线负责人，把我提交的第3级的漏洞全部标为不予解决，理由是用户不会自己攻击自己。说实话，当过我看到这个结果的时候我是很生气的（我辛辛苦苦挖了一天的洞，你给我来个不予解决就完事了？）
然后我开始琢磨怎么利用这个漏洞教训一下这些安全意识贼差的开发人员。
我突然想到之前挖到的csrf漏洞还没修复（效率太低了），于是我准备用csrf+xss配合搞一下事情。

过程如下：
1、抓包分析一下存在xss页面的提交请求为post。根据参数，构造一个恶意页面向存在xss的页面提交xss。

XSS & CSRF

其中外链的js脚本如下：

XSS

js中的php脚本如下：（跳转有点多，但是我感觉这样拆分开很灵活）

XSS & PHP

2、接下来就是把构造的页面随便放到一个服务器上，因为我是办公内网，所以我直接在我电脑上搭了一个nginx，然后去试一下：

额，有点小破绽，数据全都不显示了。不过钓鱼应该足够了。接下来就是坐等鱼儿上钩。

3、A FEW YEARS LATER.....
我得到了三条cookie

4、重新激活提交

我大概已经做到尽职尽责了吧，这回出了事就跟我没关系咯。。