这是白帽子（twitter：@spoofyroot）在2019年发布的一篇文章，完整介绍了这位师傅在挖掘Edge浏览器漏洞的思路、利用、组合。其中第三个漏洞的利用链的构造过程很有借鉴意义

在前几天的DiceCTF里，遇到了一道关于WebAssembly的题目。解题时利用Unicode字符的转换问题，使前端js脚本与WebAssembly进行交互时出现异常，以达到XSS的效果。

解题时也了解了一些关于WebAssembly的知识，算是有所收获

XSS（Cross-Site Scripting）即为跨站脚本攻击。XSS-Lab是一个XSS的练习平台。可以在BUUOJ上很方便的进行练习。以下是我在做XSS-Lab的时候总结的题解和一些思路，给想要刷题的同学提供一些参考。

这要命的大二上总算结束了（虽然还有线上考☹）
终于可以好好看看之前的比赛题。花了一天的时间，终于把Bytectf2021的Aginx系列看了个大概。

一个文件上传点是执行XSS应用程序的绝佳机会。很多网站都有用户权限上传个人资料图片的上传点，你有很多机会找到相关漏洞。如果碰巧是一个self XSS，你可以看看这篇文章。

在第一章结尾的时候我就已经说了，这一章将会更详细的介绍前端防火墙的报警机制及代码。在一章出来后，有人会问为什么不直接防御，而是不防御报警呢。很简单，因为防御的话，攻击者会定位到那一段的JavaScript代码，从而下次攻击的时候绕过代码。如果不防御而报警的话，攻击者会降低警觉，不会在看JavaScript代码（至少我是这样）。

凭借乌云漏洞报告平台的公开案例数据，我们足以管中窥豹，跨站脚本漏洞（Cross-site Script）仍是不少企业在业务安全风险排查和修复过程中需要对抗的“大敌”。

XSS可以粗分为反射型XSS和存储型XSS，当然再往下细分还有DOM XSS, mXSS（突变XSS）, UXSS(浏览器内的通用跨站脚本)。其中一部分解决方法较为简便，使用htmlspecialchars()对HTML特殊符号做转义过滤，经过转义的输入内容在输出时便无法再形成浏览器可以解析的HTML标签，也就不会形成XSS漏洞。

我不否认前端在处理XSS的时候没有后端那样方便快捷，但是很多人都在说过滤XSS的事就交给后端来做吧。前端做没什么用。我个人是非常反感这句话的。虽然说前端防御XSS比较麻烦，但是，不是一定不行。他只是写的代码比后端多了而已。而且前端防御XSS比后端防御XSS功能多，虽说后端也可以完成这些功能，但是代码量会比前端代码多很多很多。其实说了那么多，交给nginx||apache||nodeJs||Python会更好处理。但是我不会C，也就没办法写nginx模块了。而且也不在本文章的范围内，等我什么时候学会C再说把。

这又是一篇来自全职赏金猎人Masato kinugawa的神作。一次双杀，用一篇报告拿下了两个CVE，分别是CVE-2015-6144和CVE-2015-6176。报告内容指出IE的XSS Filter在对XSS攻击进行屏蔽时，由于正则的匹配不当在一些场景下会让本不存在XSS漏洞的页面产生XSS漏洞的问题。

首先声明，这不是一个新洞，看过 Homakov 文章（最后附）以及译文的人想必对这种漏洞有所了解。

但原文写的太过简单（没有说明利用条件、情景和特性），且译文和我的理解略有偏差，于是就有了这篇文章。

这种漏洞已经存在一段时间了，有没有被利用过尚不得知，虽然利用条件较苛刻，但是当符合条件的站点被攻击后， 影响面和影响程度巨大，并且普通用户不知如何清除, 可导致长期持续攻击。

前几天，在微博上看到一条关于最近的 Chrome XSS Filter Bypass 的链接：webo，原始补丁在这里：补丁。在补丁中还提供了PoC用于后续的单元测试。

近期Wordpress自身程序评论功能的Xss在微博上沸沸扬扬，而其中的修复过程也可谓一波三折，接下来由我为大家一一讲述。

PS: MBSD是一家日本安全公司，最近好像经常分享技术文档的样子。
Cross Site Script Inclusion (XSSI) 跨站脚本包含是一种攻击技术允许攻击者通过恶意js绕过边界窃取信息。具体的说，应该是通过潜入script标签加载外部数据，for example: