├── source ├── _static │ └── .gitkeep ├── ref │ ├── resources.rst │ ├── index.rst │ ├── manual.rst │ ├── tool.rst │ ├── vuln.rst │ ├── blog.rst │ └── paper.rst ├── browsers │ ├── firefox.rst │ ├── jsc.rst │ ├── index.rst │ ├── ie.rst │ ├── webkit.rst │ ├── v8.rst │ ├── edge.rst │ ├── chakra.rst │ └── chrome.rst ├── images │ ├── chakra │ │ ├── gc.png │ │ ├── class.jpg │ │ ├── framework.png │ │ ├── pipeline.png │ │ ├── execution_contexts.png │ │ ├── JavascriptFunctionClass.jpg │ │ ├── Type-StaticTypesharing.png │ │ ├── Type-ObjectLayout-TypePath.png │ │ └── Type-ObjectLayout-sharing.png │ ├── chrome-frame.png │ ├── webkit-frame.jpg │ └── webkit-rendeer.jpg ├── papers │ ├── fuzzil.rst │ ├── index.rst │ ├── scheduled.rst │ ├── predicting.rst │ ├── langfuzz.rst │ ├── fileja.rst │ ├── domlevel.rst │ ├── notallbytes.rst │ ├── mongo.rst │ ├── skyfire.rst │ ├── blonefuzz.rst │ └── gramfuzz.rst ├── fuzzers │ ├── index.rst │ ├── jsfunfuzz.rst │ ├── afl.rst │ ├── implementation.rst │ └── grinder.rst ├── intro │ ├── index.rst │ ├── webidl.rst │ ├── security.rst │ ├── js.rst │ ├── html.rst │ ├── render.rst │ ├── dom.rst │ ├── mitigation.rst │ ├── kernel.rst │ ├── wasm.rst │ └── vultype.rst ├── index.rst ├── fuzz.rst └── conf.py ├── Makefile ├── make.bat ├── README.md ├── .gitignore └── LICENSE /source/_static/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /source/ref/resources.rst: -------------------------------------------------------------------------------- 1 | 资源 2 | ================================ 3 | -------------------------------------------------------------------------------- /source/browsers/firefox.rst: -------------------------------------------------------------------------------- 1 | Firefox 2 | ================================ 3 | -------------------------------------------------------------------------------- /source/images/chakra/gc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/gc.png -------------------------------------------------------------------------------- /source/images/chakra/class.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/class.jpg -------------------------------------------------------------------------------- /source/images/chrome-frame.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chrome-frame.png -------------------------------------------------------------------------------- /source/images/webkit-frame.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/webkit-frame.jpg -------------------------------------------------------------------------------- /source/images/chakra/framework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/framework.png -------------------------------------------------------------------------------- /source/images/chakra/pipeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/pipeline.png -------------------------------------------------------------------------------- /source/images/webkit-rendeer.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/webkit-rendeer.jpg -------------------------------------------------------------------------------- /source/papers/fuzzil.rst: -------------------------------------------------------------------------------- 1 | Fuzzil: Coverage Guided Fuzzing for JavaScript Engines 2 | ======================================================== 3 | -------------------------------------------------------------------------------- /source/images/chakra/execution_contexts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/execution_contexts.png -------------------------------------------------------------------------------- /source/images/chakra/JavascriptFunctionClass.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/JavascriptFunctionClass.jpg -------------------------------------------------------------------------------- /source/images/chakra/Type-StaticTypesharing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/Type-StaticTypesharing.png -------------------------------------------------------------------------------- /source/images/chakra/Type-ObjectLayout-TypePath.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/Type-ObjectLayout-TypePath.png -------------------------------------------------------------------------------- /source/images/chakra/Type-ObjectLayout-sharing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LyleMi/Browser-Fuzz-Summarize/HEAD/source/images/chakra/Type-ObjectLayout-sharing.png -------------------------------------------------------------------------------- /source/fuzzers/index.rst: -------------------------------------------------------------------------------- 1 | Fuzzers 2 | ================================ 3 | 4 | .. toctree:: 5 | :maxdepth: 2 6 | :caption: 内容索引: 7 | 8 | implementation 9 | grinder 10 | afl 11 | jsfunfuzz 12 | -------------------------------------------------------------------------------- /source/ref/index.rst: -------------------------------------------------------------------------------- 1 | 参考资料 2 | ================================ 3 | 4 | .. toctree:: 5 | :maxdepth: 2 6 | :caption: 内容索引: 7 | 8 | paper 9 | tool 10 | blog 11 | vuln 12 | manual 13 | resources 14 | -------------------------------------------------------------------------------- /source/browsers/jsc.rst: -------------------------------------------------------------------------------- 1 | JavaScriptCore 2 | ================================ 3 | 4 | 参考链接 5 | ---------------------------------------- 6 | - `深入剖析 JavaScriptCore `_ 7 | -------------------------------------------------------------------------------- /source/browsers/index.rst: -------------------------------------------------------------------------------- 1 | 浏览器与引擎 2 | ================================ 3 | 4 | .. toctree:: 5 | :maxdepth: 2 6 | :caption: 内容索引: 7 | 8 | chrome 9 | firefox 10 | webkit 11 | edge 12 | ie 13 | v8 14 | chakra 15 | jsc 16 | -------------------------------------------------------------------------------- /source/intro/index.rst: -------------------------------------------------------------------------------- 1 | 基础知识 2 | ======================================== 3 | 4 | .. toctree:: 5 | :maxdepth: 2 6 | :caption: 内容索引: 7 | 8 | kernel 9 | html 10 | dom 11 | js 12 | render 13 | webidl 14 | wasm 15 | security 16 | vultype 17 | mitigation 18 | -------------------------------------------------------------------------------- /source/index.rst: -------------------------------------------------------------------------------- 1 | 浏览器模糊测试综述 2 | ================================================== 3 | 4 | .. toctree:: 5 | :numbered: 6 | :maxdepth: 2 7 | :caption: 内容索引: 8 | 9 | intro/index 10 | browsers/index 11 | papers/index 12 | fuzz 13 | fuzzers/index 14 | ref/index 15 | -------------------------------------------------------------------------------- /source/papers/index.rst: -------------------------------------------------------------------------------- 1 | 相关论文 2 | ================================ 3 | 4 | .. toctree:: 5 | :maxdepth: 2 6 | :caption: 内容索引: 7 | 8 | blonefuzz 9 | langfuzz 10 | domlevel 11 | fileja 12 | gramfuzz 13 | mongo 14 | notallbytes 15 | predicting 16 | scheduled 17 | skyfire 18 | fuzzil 19 | -------------------------------------------------------------------------------- /source/papers/scheduled.rst: -------------------------------------------------------------------------------- 1 | Scheduled DOM Fuzzing 2 | ================================================== 3 | 4 | 该方法[1-1]是基于一些有联系的浏览器fuzz工具和一个名为BFF的fuzz框架结合后优化得来。这种方法对fuzz做出的主要优化是并不以同等的概率选择种子以及种子变换的概率，而是在fuzz的过程中，计算更容易产生crash的种子以及变换方式，从而动态的变化选择种子/变换方式的概率，以期以更高的概率获得crash。该篇文章的实验部分对比了zzuf、crossfuzz等fuzz方式，获得了倍于这些工具的crash，以此认为该方法是有效的。 5 | -------------------------------------------------------------------------------- /source/fuzzers/jsfunfuzz.rst: -------------------------------------------------------------------------------- 1 | jsfunfuzz 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | Jsfunfuzz使用了历史漏洞知识和硬编码规则生成测试输入，以Mozilla浏览器中的Javascript解释器为测试目标。 7 | 8 | 参考链接 9 | ---------------------------------------- 10 | - `funfuzz `_ 11 | -------------------------------------------------------------------------------- /source/intro/webidl.rst: -------------------------------------------------------------------------------- 1 | WebIDL 2 | ================================================== 3 | 4 | 简介 5 | -------------------------------------------------- 6 | Web IDL是一种接口定义语言（Interface Definition Language，IDL）的变体。 7 | 8 | W3C发布的包含编程语言接口的技术报告通常使用IDL进行描述，其提供了一种以独立于语言的方式描述这些接口的方法。 9 | 10 | 一个Web API的定义会包含一个到多个IDL片段，一个IDL片段是满足定义语法的定义组成的序列。 11 | -------------------------------------------------------------------------------- /source/papers/predicting.rst: -------------------------------------------------------------------------------- 1 | predicting vulnerable software components 2 | ================================================== 3 | 4 | 这篇文章的主要贡献在于给出了一个预测在大型软件中，某个模块漏洞出现概率的方法。可以通过该方法预测更容易出现漏洞的模块，从而有针对性的进行审计。 5 | 该文章使用的主要方法为从https://bugzilla.mozilla.org中获取了firefox历年来的漏洞，使用机器学习的方法对其进行聚类。 6 | 7 | 个人觉得这个思路是可以借鉴的，如果白盒符号执行的时候路径过多，可以使用该方式进行启发式的路径选择，从而更高效的测试。 8 | -------------------------------------------------------------------------------- /source/browsers/ie.rst: -------------------------------------------------------------------------------- 1 | IE 2 | ======================================== 3 | 4 | 缓解技术 5 | ---------------------------------------- 6 | - 堆隔离技术 7 | - 延迟释放技术 8 | - 控制流保护技术 9 | 10 | 参考链接 11 | ---------------------------------------- 12 | - `IE浏览器缓解技术逆向初探 `_ 13 | - `IE：从一字节改写到全地址读写 `_ 14 | -------------------------------------------------------------------------------- /source/intro/security.rst: -------------------------------------------------------------------------------- 1 | 浏览器安全 2 | ======================================== 3 | 4 | 安全机制 5 | ---------------------------------------- 6 | - 同源策略 (SOP) 7 | - XSS 过滤器 8 | - CSP (内容安全策略) 9 | - 扩展/插件安全 10 | - 渲染引擎安全 11 | - JavaScript引擎安全 12 | - 运行架构安全 13 | 14 | 挖掘思路 15 | ---------------------------------------- 16 | - 检查新功能 17 | - Firefox Nightly 18 | - Chrome Dev Canary 19 | - Safari Technology Preview 20 | 21 | -------------------------------------------------------------------------------- /source/fuzzers/afl.rst: -------------------------------------------------------------------------------- 1 | AFL 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | AFL（American Fuzzy Lop）是由安全研究员Michał Zalewski（@lcamtuf）开发的一款覆盖制导的模糊测试工具，它通过记录输入样本的代码覆盖率，从而调整输入样本以提高覆盖率，增加发现漏洞的概率。 7 | 8 | 其工作流程大致如下： 9 | 10 | - 从源码编译程序时进行插桩，以记录代码覆盖率 11 | - 选择一些输入文件，作为初始测试集加入输入队列 12 | - 将队列中的文件按一定的策略进行变异 13 | - 如果经过变异文件更新了覆盖范围，则将其保留添加到队列中 14 | - 上述过程会一直循环进行，期间触发了crash的文件会被记录下来 15 | -------------------------------------------------------------------------------- /source/papers/langfuzz.rst: -------------------------------------------------------------------------------- 1 | Fuzzing with Code Fragments 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | Fuzzing with Code Fragments 这篇论文介绍了一个名为 LangFuzz 的模糊测试器。 LangFuzz 利用给定的编程语言的语法来生成代码，由代码示例和变异引擎来创建测试用例。 7 | 8 | 参考链接 9 | ---------------------------------------- 10 | - `Fuzzing with Code Fragments `_ 11 | -------------------------------------------------------------------------------- /source/papers/fileja.rst: -------------------------------------------------------------------------------- 1 | Fileja 2 | ================================================== 3 | 4 | fileja在nduja的基础上有两个比较大的改进的地方 5 | 一个是增加了一些对时间敏感的操作，这个是针对 6 | 所有浏览器的 7 | 8 | 另外，对于IE支持的多脚本引擎的特性，也特别做了fuzz 9 | 10 | 这里提到的时间敏感的操作主要是说之前的文章对DOM的操作都是同步的 11 | 而在这篇文章中引入了xhr和WebSocket 12 | 13 | 主要有这三种fuzz的行为： 14 | 15 | - 同步/异步server返回 16 | - 通过setTimeout 或 setInterval API同时运行多个call 17 | - 任意时间延迟 18 | 19 | 这样则将导致 20 | 21 | - 在一个API调用的中间会触发一次DOM的变化 22 | - ws/xhr的配置还没有改动但是主页面已经跳转了 23 | - race condition 24 | 25 | -------------------------------------------------------------------------------- /source/intro/js.rst: -------------------------------------------------------------------------------- 1 | JavaScript 引擎 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | JavaScript引擎是一个专门处理JavaScript脚本的虚拟机，一般会附带在网页浏览器之中。 7 | 8 | 常见引擎 9 | ---------------------------------------- 10 | - V8 (Chrome) 11 | - SpiderMonkey (FireFox) 12 | - ChakraCore (Edge) 13 | - JavaScriptCore (Safari) 14 | 15 | 执行 16 | ---------------------------------------- 17 | - JavaScript源代码被Parser解析成AST 18 | - AST经Interpreter解析成Bytecode后执行 19 | - 不断执行Bytecode，收集运行时信息，生成优化后的Bytecode 20 | -------------------------------------------------------------------------------- /source/papers/domlevel.rst: -------------------------------------------------------------------------------- 1 | DOM Level Fuzz 2 | -------------------------------------------------- 3 | 4 | 这是Nduja[3-5]实现的主要的思路。该方法认为基于DOM的Fuzz可以分为三个层次，第一层是常规的随机生成元素，这种思路是最普遍的，所以效率不高。作者认为应该从更高的层次去fuzz。比如基于DOM的第二（基于逻辑）第三层（基于事件）进行fuzz，以期获得更好的效果。 5 | 6 | 从第二层出发，更多考虑的是基于DOM逻辑进行变换。举例来说，在一棵DOM树上，存在的逻辑有firstChild/lastChild/nextNode/previousNode/nextSiebling/previousSiebling等，而节点则存在detach/attach/nextNode/previousNode等逻辑，可以基于这相关的逻辑进行变换。 7 | 8 | 第三层考虑的是DOM之间发生变化时相应触发的事件。利用事件之间的逻辑关系去fuzz，比如节点A发生detach时，会触发让该节点attach到节点B的动作，但是又会触发节点删除子节点的动作。用这样一些逻辑上的边界条件去尝试fuzz。 9 | -------------------------------------------------------------------------------- /source/papers/notallbytes.rst: -------------------------------------------------------------------------------- 1 | Not all bytes are equal Neural byte sieve for fuzzing 2 | ======================================================= 3 | 4 | 这篇文章的想法很直接，考虑到一个结构化的输入，在某些点变异会比在其他地方变异更有用，于是就产生了先预测变异的热力图，然后再变异的想法。 5 | 6 | 文中先在有限的时间内进行正常的模糊测试的流程，拿到样本及其覆盖率对模型进行训练。考虑到输入是一个连续的字节流，使用LSTM算法来建立模型。 7 | 8 | 训练模型用四个参数 9 | 10 | - 输入 11 | - 输入对应的覆盖 12 | - 变异后的输入 13 | - 变异后的输入对应的覆盖 14 | 15 | 模型把输入转成一个向量，输出的热力图也是一个向量，向量的每个单位是一个字节，表示变异这里带来覆盖率提升的可能性。 16 | 模型建立好后，用这个热度图来指导变异，先diff变异前后的样本，得到一个新的向量，变异记为1，否则为0。用这个新的向量乘上对应的heapmap，如果结果大于设置好的阈值，就对该变异进行测试。 17 | -------------------------------------------------------------------------------- /source/intro/html.rst: -------------------------------------------------------------------------------- 1 | HTML 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | HTML 语法定义HTML 的词汇和语法在 W3C 组织创建的规范中进行了定义。 7 | 8 | HTML 的定义采用了 DTD 格式。此格式可用于定义 SGML 族的语言。它包括所有允许使用的元素及其属性和层次结构的定义。如上文所述，HTML DTD 无法构成与上下文无关的语法。 9 | 10 | DTD 存在一些变体。严格模式完全遵守 HTML 规范，而其他模式可支持以前的浏览器所使用的标记。这样做的目的是确保向下兼容一些早期版本的内容。最新的严格模式 DTD 可以在这里找到：www.w3.org/TR/html4/strict.dtd 。 11 | 12 | 容错机制 13 | ---------------------------------------- 14 | 浏览器会修改一些错误内容。 15 | 16 | 主流的修复规则如下： 17 | 18 | - 存在明显不能在某些外部标记中添加的元素时，关闭所有标记，直到出现禁止添加的元素，然后再加入该元素 19 | - 向 inline 元素内添加 block 元素。关闭所有 inline 元素，直到出现下一个较高级的 block 元素 20 | -------------------------------------------------------------------------------- /source/papers/mongo.rst: -------------------------------------------------------------------------------- 1 | MongoDB's JavaScript Fuzzer 2 | ================================================== 3 | 4 | 这篇文章是由MongoDB开发者为这个项目写的fuzzer的一个总结。 5 | 6 | 许多fuzzer都依赖明确的语法来生成测试，这种语法使得这些测试变得更加智能。但是在这个fuzzer中，作者并没有直接构建语法库，而是从JavaScript集成测试语料库中借鉴了MongoDB命令语法的知识，随机地突变它们以创建新的测试用例。 7 | 8 | 当fuzzer运行时，它使用JS测试的随机子集作为种子。Fuzzer将它们转换为JavaScript解释器可以理解的形式的AST。 然后，通过有选择地替换节点，对其进行随机化并替换它们的值，在树上造成受控制的破坏。这样就可以测试正常测试中不会遇到的参数生成命令，但是保留了有效的JavaScript对象的整体结构。 9 | 10 | 这个fuzzer在变异的时候的优点有 11 | 12 | - 使用基于AST替换而不是正则 13 | - 使用启发式的替换而不是完全随机 14 | - 在要替换时，更多的替换容易产生的问题的值或者类型 15 | 16 | 但是这样的fuzzer会有一个盲点，因为语料库全部来自于人工的测试样例，所以难免有所遗漏，所以作者也加入了一些随机的字符串样本来盲测作为这个缺点的弥补 17 | -------------------------------------------------------------------------------- /source/papers/skyfire.rst: -------------------------------------------------------------------------------- 1 | Skyfire Data-Driven Seed Generation for Fuzzing 2 | ================================================== 3 | 4 | 这篇文章主要想解决的问题是语法严格的程序一般有语法解析、语义检查然后执行。想要生成有效语义的case的代价是非常昂贵的。而一般的bug是在执行阶段，这为Fuzz带来了难度。 5 | 6 | 文章主要的贡献是在AST和CFG的基础上提出了Probabilistic Context Sensitive Grammar (PCSG)。从样本中学习出可以描述语法和语义的PCSG。再使用PCSG生成正确的，多样化的，不常见的Case。 7 | 8 | 但是这样生成有几个问题，因为一些生成规则是递归的，那么就可以生成很大的样本，因此文中增加了一些启发式的算法。包括： 9 | 10 | - Heuristic 1: Favor low-probability production rules 11 | - Heuristic 2: Favor low-frequency production rules 12 | - Heuristic 3: Favor low-complex production rules 13 | - Heuristic 4: Restrict the total number of rule applications 14 | 15 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # Minimal makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = python -msphinx 7 | SPHINXPROJ = browser_fuzz_summarize 8 | SOURCEDIR = source 9 | BUILDDIR = build 10 | 11 | # Put it first so that "make" without argument is like "make help". 12 | help: 13 | @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 14 | 15 | .PHONY: help Makefile 16 | 17 | # Catch-all target: route all unknown targets to Sphinx using the new 18 | # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). 19 | %: Makefile 20 | @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) -------------------------------------------------------------------------------- /source/intro/render.rst: -------------------------------------------------------------------------------- 1 | 渲染 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | 渲染引擎解析 HTML 文档，并将各标记逐个转化成 DOM 节点。同时也会解析外部 CSS 文件以及样式元素中的样式数据。 7 | 8 | Render树 9 | ---------------------------------------- 10 | - Render树包含若干带有颜色、面积等可视化属性的矩形 11 | - 矩形按照在屏幕上展现的顺序排列 12 | - 并不是所有DOM树的节点都有对应的Render树，不可见元素就没有在Render树中 13 | 14 | 构建流程 15 | ---------------------------------------- 16 | - 根节点在处理HTML中的body标签时构建，其余部分随DOM节点插入而构建 17 | - 样式计算：计算每一个渲染对象的可视化属性 18 | - 按照连接序应用样式规则 19 | - 继承规则 20 | - 赋默认值 21 | - 根据目标媒介，生成渲染对象 22 | - 屏幕：visual flow 模型 23 | - 可打印设备：page 模型 24 | - 语音渲染设备：aural rendering 模型 25 | 26 | 布局过程 27 | ---------------------------------------- 28 | - 赋予每一个Render树节点在屏幕中出现的准确坐标 29 | - 采用流模型（从左到右 从上到下） 30 | - 坐标系的原点在左上 31 | - 采用全局和增量式布局 32 | - 全局样式改变影响局部渲染 33 | - 变化的矩形被重新布局 34 | -------------------------------------------------------------------------------- /source/intro/dom.rst: -------------------------------------------------------------------------------- 1 | DOM 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | DOM是文档对象模型(Document Object Model)的缩写，标准由 W3C 组织指定。DOM树是把 HTML 文档呈现为带有元素、属性和文本的树结构。 7 | 8 | DOM标准 9 | ---------------------------------------- 10 | DOM标准也在不断在演进，到目前有三个级别。 11 | 12 | - DOM Level 1 13 | - Core: 可表示任何结构化文档的基础性底层接口集合 14 | - HTML: 基于Core接口，提供更适合的HTML的高层接口 15 | - DOM Level 2 16 | - Core: 扩展Level 1 Core 17 | - Views: 程序或脚本动态访问和更新文档表示的内容 18 | - Events: 程序和脚本可使用的通用事件系统 19 | - Styles: 程序或脚本动态访问和更新样式数据的内容 20 | - Traversal and Range: 程序或脚本动态遍历或标识文档中的一段内容 21 | - HTML: 程序或脚本动态访问和更新HTML文档的结构和内容 22 | - DOM Level 3 23 | - Core: 扩展Level 1 和 2 的 Core 24 | - Load and Save：程序或脚本动态将XML文档加载到DOM文档中，将DOM序列化为XML 25 | - Validation： 程序或脚本在保证文档合法的基础上动态更新文档的内容 26 | - Events： 扩展Level 2 Events，主要增加键盘事件 27 | - Xpath: 使用Xpath访问DOM树 28 | -------------------------------------------------------------------------------- /source/ref/manual.rst: -------------------------------------------------------------------------------- 1 | 规范 / 手册 2 | ================================ 3 | - `wc3规范 `_ 4 | - `DOM规范 `_ 5 | - `whatwg `_ 6 | - `MDN `_ 7 | - `Mozilla Source Tree Documentation `_ 8 | - `HTML Standard by whatwg `_ 9 | - `V8 Documentation `_ 10 | - `chromium documents `_ 11 | - `chromium design documents `_ 12 | - `V8 Ignition online doc `_ 13 | - `SpiderMonkey `_ 14 | - `WebAssembly `_ 15 | -------------------------------------------------------------------------------- /make.bat: -------------------------------------------------------------------------------- 1 | @ECHO OFF 2 | 3 | pushd %~dp0 4 | 5 | REM Command file for Sphinx documentation 6 | 7 | if "%SPHINXBUILD%" == "" ( 8 | set SPHINXBUILD=python -msphinx 9 | ) 10 | set SOURCEDIR=source 11 | set BUILDDIR=build 12 | set SPHINXPROJ=browser_fuzz_summarize 13 | 14 | if "%1" == "" goto help 15 | 16 | if errorlevel 9009 ( 17 | echo. 18 | echo.The Sphinx module was not found. Make sure you have Sphinx installed, 19 | echo.then set the SPHINXBUILD environment variable to point to the full 20 | echo.path of the 'sphinx-build' executable. Alternatively you may add the 21 | echo.Sphinx directory to PATH. 22 | echo. 23 | echo.If you don't have Sphinx installed, grab it from 24 | echo.http://sphinx-doc.org/ 25 | exit /b 1 26 | ) 27 | 28 | %SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% 29 | goto end 30 | 31 | :help 32 | %SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% 33 | 34 | :end 35 | popd 36 | -------------------------------------------------------------------------------- /source/intro/mitigation.rst: -------------------------------------------------------------------------------- 1 | 浏览器防护措施 2 | ================================================== 3 | 4 | Edge 5 | -------------------------------------------------- 6 | 7 | ACG (Arbitrary Code Guard) 8 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 9 | - ACG防止进程生成动态代码或者修改已经存在的可执行文件。这个是用ProcessDynamicCodePolicy来配置的。 10 | 11 | - 有两个 W^X 策略 12 | - 存在的代码页不可写 13 | - 没有签名的代码页不能被创建 14 | - 使用内存保护的手段来加固内核函数 15 | - NtProtectVirtualMemory 16 | - NtAllocateVirtualMemory 17 | - NtMapViewOfSection 18 | - 其他 19 | 20 | CIG (Code Integrity Guard) 21 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 22 | - CIG禁止进程载入没有签名的镜像，使用ProcessSignaturePolicy来配置 23 | - 在创建section的内核函数NtCreateSection中强制 24 | - 使用ProcessImageLoadPolicy防止载入不受信任的镜像 25 | 26 | CFG (Control Flow Guard) 强制控制流完整性 27 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 28 | - CFG防止程序的控制流被劫持，使用ProcessControlFlowGuardPolicy来配置。 29 | - 每次跳转的目标都是受控的，检查写在ntdll.dll的LdrpValidateUserCallTarget / LdrpDispatchUserCallTarget等函数 30 | - CFG不能保护基于ret的跳转 31 | -------------------------------------------------------------------------------- /source/intro/kernel.rst: -------------------------------------------------------------------------------- 1 | 浏览器简介 2 | ================================================== 3 | 4 | 浏览器结构 5 | -------------------------------------------------- 6 | 浏览器一般包括DOM引擎、CSS解释器、脚本引擎、渲染引擎、协议支持、媒体流支持、三方库、数据存储、用户界面等几个部分。 7 | 8 | DOM引擎解析HTML、XML、SVG、MathML、XUL等内容。 9 | 10 | CSS解释器解析CSS，为DOM中的各个元素计算样式信息。 11 | 12 | 渲染引擎根据元素与样式信息，计算大小、位置、布局，渲染解析后的内容。 13 | 14 | 脚本引擎包括JavaScript、VBScript、asm.js、WebAssembly等解释器，对脚本进行解释执行，并对DOM、CSS进行修改。 15 | 16 | 浏览器支持的协议通常包括HTTP、FTP、WebSocket、HTTP/2、QUIC、DNS、mDNS、WebRTC等。 17 | 18 | 浏览器支持的媒体流通常包括JPG、GIF、PNG、WebM、Ogg、AAC、MP3、MP4、FLAC等。 19 | 20 | 三方库包括Skia, ffmpeg, ICU, NSS, OpenVR, libpng, sqlite等。 21 | 22 | 用户界面包括地址栏、前进/后退按钮、书签菜单等。 23 | 24 | 浏览器内核 25 | -------------------------------------------------- 26 | 浏览器内核比较主要的两部分是渲染引擎(Layout engineer或Rendering Engine)和JavaScript引擎。 27 | 28 | 渲染引擎负责取得网页的内容(HTML、XML、图像等等)、整理讯息(例如加入CSS等)，以及计算网页的显示方式，然后会输出至显示器或打印机。 29 | 30 | 浏览器的内核的不同对于网页的语法解释会有不同，所以渲染的效果也不相同。所有网页浏览器、电子邮件客户端以及其它需要编辑、显示网络内容的应用程序都需要内核。 31 | 32 | JavaScript引擎则解析和执行JavaScript来实现网页的动态效果。最开始渲染引擎和JavaScript引擎并没有区分的很明确，后来JavaScript引擎越来越独立，内核就倾向于只指渲染引擎。 33 | -------------------------------------------------------------------------------- /source/intro/wasm.rst: -------------------------------------------------------------------------------- 1 | WebAssembly 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | WebAssembly是在Web中引入的低级语言，其目的和Asm.js类似，也是要支持本地代码的运行从而获得媲美原生应用的高性能。 7 | 8 | 它是一种二进制语言，但是无法直接在处理器上运行。在运行时，代码被编译为中间字节代码，可以在浏览器内快速转换为机器代码，然后比传统JavaScript更有效地执行。 9 | 10 | 执行 11 | ---------------------------------------- 12 | 虽然浏览器可能以不同的方式来实现Wasm支持，但是使用的沙盒环境通常是JavaScript沙箱。 13 | 14 | 在浏览器中运行时，Wasm应用程序需要将其代码定义为单独的文件或JavaScript块内的字节数组。 然后使用JavaScript实例化文件或代码块，目前不能在没有JavaScript包装器的情况下直接在页面中调用Wasm。 15 | 16 | 虽然Wasm可以用C / C++等语言编写，但它本身不能与沙箱之外的环境进行交互。这意味着当Wasm应用程序想要进行输出文本等操作时，它需要调用浏览器提供的功能，然后使用浏览器在某处输出文本。 17 | 18 | Wasm中的内存是线性的，它在Wasm应用程序和JavaScript之间共享。 当Wasm函数将字符串返回给JavaScript时，它实际上返回一个指向Wasm应用程序内存空间内位置的指针。 Wasm应用程序本身只能访问分配给它的JavaScript内存部分，而不是整个内存空间。 19 | 20 | 安全 21 | ---------------------------------------- 22 | Wasm的设计从如下几个方面考虑来保证Wasm的安全性 23 | 24 | - 保护用户免受由于无意的错误而导致漏洞的应用程序的侵害 25 | - 保护用户免受故意编写为恶意的应用程序的侵害 26 | - 为开发人员提供良好的缓解措施 27 | 28 | 具体的安全措施有 29 | 30 | - Wasm应用程序在沙箱内运行 31 | - Wasm无法对任意地址进行函数调用。Wasm采用对函数进行编号的方式，编号存储在函数表中 32 | - 间接函数调用受类型签名检查的约束 33 | - 调用堆栈受到保护，这意味着无法覆盖返回指针 34 | - 实现了控制流完整性，这意味着调用意外的函数将失败 35 | -------------------------------------------------------------------------------- /source/ref/tool.rst: -------------------------------------------------------------------------------- 1 | 工具 2 | ================================ 3 | - `zuff fuzzer `_ 4 | - `CERT Basic Fuzzing `_ 5 | - `CERT Failure Observation Engine `_ 6 | - `bf3 `_ 7 | - `Grinder `_ 8 | - `axman `_ 9 | - `exploitable `_ 10 | - `jsfunfuzz `_ 11 | - `metasm `_ 12 | - `web platform tests `_ 13 | - `oss fuzz `_ 14 | - `Domato `_ 15 | - `mitigationview `_ 16 | - `sandbox attacksurface analysis tools `_ 17 | - `NodeFuzz `_ 18 | - `wadi `_ 19 | - `Angora `_ 20 | - `afl `_ 21 | - `neuzz `_ 22 | -------------------------------------------------------------------------------- /source/papers/blonefuzz.rst: -------------------------------------------------------------------------------- 1 | one fuzzing template revealed over 100 IE UAF 2 | ================================================== 3 | 4 | 这篇文章出自black hat Europe 2014的一篇讲稿 5 | 6 | 作者提出 7 | 8 | :: 9 | 10 | – Engineers are not good at repairing 11 | – Engineers make mistakes taking things apart (undoing) 12 | – Engineers made mistakes putting things back together (redoing) 13 | 14 | 从这里就延伸出去想到工程师可能会犯错的地方，然后fuzzer就从下面这些地方的思路开始构造 15 | 16 | - Explicit Pairings 17 | – Direct: 'on/off', 'true/false', properties. 18 | - e.g. 19 | 20 | + ``display="block"/"none"`` 21 | + ``appendChild/removeChild`` 22 | + addEventListener : ``focusin/focusout`` 23 | - Implicit Pairings 24 | - Indirect: inheritance, nullity, state change. 25 | - e.g. 26 | 27 | + Content: ``innerText=''/ document.write('')`` 28 | + Relation: swap parent/child node 29 | + Status: ``window.navigate('') / location.reload()`` 30 | - Hybrid Pairings 31 | - Complexity of mixing explicit and implicit. 32 | - Script (Dynamic) + HTML (Static) 33 | 34 | + ```` 35 | + ``Document.body.contentEditable='false';`` 36 | - Property + Method 37 | - Pairing Combinations 38 | – Multiple pairings per page. 39 | -------------------------------------------------------------------------------- /source/browsers/webkit.rst: -------------------------------------------------------------------------------- 1 | Webkit 2 | ================================ 3 | 4 | 简介 5 | -------------------------------- 6 | Webkit主要由WebCore和JavaScript Core组成，除此之外，WebKit Embedding API是负责浏览器UI与WebKit进行交互的部分，而WebKit Ports则是让Webkit更加方便的移植到各个操作系统、平台上，提供的一些调用Native Library的接口。 7 | 8 | JavaScript Core 9 | -------------------------------- 10 | JavaScript Core的优化执行分为四个部分，LLInt、Baseline、DFG、FTL。 11 | LLInt是最开始的解释执行部分，Baseline是暂时的JIT，DFG阶段开始做一定的优化，FTL阶段做了充分的优化。 12 | 13 | 编译 14 | -------------------------------- 15 | :: 16 | 17 | apt update 18 | apt install flatpak libseccomp-dev 19 | git clone https://github.com/projectatomic/bubblewrap 20 | ./autogen.sh 21 | ./configure 22 | make 23 | make insatll 24 | git clone --depth=1 git://git.webkit.org/WebKit.git 25 | cd WebKit 26 | echo Y | ./Tools/gtk/install-dependencies 27 | ./Tools/Scripts/update-webkitgtk-libs 28 | ./Tools/Scripts/build-webkit --release --gtk --cmakeargs=-DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer -g -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++" 29 | add-apt-repository ppa:alexlarsson/flatpak 30 | ./Tools/Scripts/run-minibrowser --gtk 31 | 32 | 参考链接 33 | -------------------------------- 34 | - `WEBKIT渲染不可不知的这四棵树 `_ 35 | -------------------------------------------------------------------------------- /source/papers/gramfuzz.rst: -------------------------------------------------------------------------------- 1 | GramFuzz Fuzzing 2 | ================================================== 3 | 4 | 该方法[1-7]的改进点主要有两个。一个在于不直接生成种子，而是从网上获取已经有的HTML文档，并对其进行分析后获得一个比较庞大的语法库，然后使用语法库获得种子。变换方法则更基于语法规则进行变化，而不是随机生成一些值。 5 | 6 | 尝试把其主要流程写成了如下的伪代码： 7 | 8 | 主流程伪代码 9 | -------------------------------------------------- 10 | 11 | :: 12 | 13 | webFiles = Crawler.getHTMLfromInternet() 14 | trainSets = new TrainSets(webFiles) 15 | initCases = new InitialCases(webFiles, Pocs) 16 | grammarLibrary = {JsLib, HTMLLib, CSSLib} = new GrammarLibrary(trainSets) 17 | grammarNode = new GrammarNode(grammarLibrary) 18 | testCases = new Testcases(grammarNode, mutatePattern(initCases)) 19 | 20 | 21 | Extract the Grammar Node 22 | -------------------------------------------------- 23 | 24 | :: 25 | 26 | currentNode = rootNode 27 | grammarNodeDB = [] 28 | 29 | def searchLeafNode(n): 30 | tmp = new Node() 31 | tmp.code = n.code 32 | tmp.type = n.type 33 | grammarNodeDB.push(tmp) 34 | 35 | 36 | def searchChildNode(n): 37 | searchLeafNode(n) 38 | tmp = n.nextLeafNode() 39 | while tmp is not None: 40 | searchLeafNode(tmp) 41 | tmp = n.nextLeafNode() 42 | 43 | def main(rootNode): 44 | searchChildNode(rootNode) 45 | 46 | 该文章的主要优点在于测试者不需要对DOM树，CSS，或者Js语法有了解，只要使用代码库就可以了。另外，从真实HTML文件中的代码会对接口有更高的覆盖率，而且生成测试样例使用了语法树的方法，给测试例子触发漏洞以更多的可能性。 47 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 浏览器模糊测试综述 2 | 3 | 对浏览器模糊测试相关知识、论文、工具进行整理。尚有缺漏或未完成的部分，持续更新中，如有错误请不吝指出。在完成的过程中参考了一些blog、文献，皆在最后给出相应链接，感谢blog作者的分享。 4 | 5 | ## 索引 6 | 7 | - 基础知识 8 | - 浏览器内核简介 9 | - JavaScript引擎 10 | - Chrome 11 | - Webkit 12 | - Edge 13 | - ChakraCore 14 | - WebIDL 15 | - WebAssembly 16 | - 相关论文 17 | - one fuzzing template revealed over 100 IE UAF 18 | - DOM Level Fuzz 19 | - Fileja 20 | - GramFuzz Fuzzing 21 | - MongoDB’s JavaScript Fuzzer 22 | - Not all bytes are equal Neural byte sieve for fuzzing 23 | - predicting vulnerable software components 24 | - Scheduled DOM Fuzzing 25 | - Skyfire Data-Driven Seed Generation for Fuzzing 26 | - 浏览器防护措施 27 | - Edge 28 | - 浏览器漏洞类型 29 | - 信息泄漏漏洞 30 | - 内存破坏漏洞 31 | - 沙箱逃逸漏洞 32 | - 扩展和插件漏洞 33 | - UI欺骗 34 | - 特权域 XSS + 特权域 API 35 | - Fuzz方法 36 | - 白盒fuzz 37 | - 黑盒fuzz 38 | - 灰盒fuzz 39 | - Fuzz实现 40 | - 综述 41 | - 随机样本的生成 42 | - 样本保存 43 | - 其他样本生成方式 44 | - 浏览器进程监控 45 | - 浏览器fuzz缺点 46 | - Grinder 47 | - 客户端配置 48 | - Node 49 | - Server 50 | - metasm 51 | - Fuzzer编写 52 | - nduja 53 | - fileja 54 | - 参考资料 55 | - 参考文献 56 | - 工具 57 | - Blog or Talks 58 | - 漏洞相关 59 | 60 | ### 生成 HTML 格式的文档 61 | 62 | ```shell 63 | git clone https://github.com/LyleMi/Browser-Fuzz-Summarize.git bfs 64 | pip install sphinx 65 | pip install sphinx-rtd-theme 66 | make html 67 | ``` 68 | 69 | ### 反馈 70 | 71 | 欢迎大家提出各种意见和建议，不胜感激。 72 | 73 | 反馈邮箱 ``lylemi@126.com`` 74 | -------------------------------------------------------------------------------- /source/browsers/v8.rst: -------------------------------------------------------------------------------- 1 | V8 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | V8是一个JavaScript引擎的实现，使用C++开发。在运行JavaScript之前，V8将其编译成原生机器码，并且使用了内联缓存（inline caching）等方法来提高性能。 7 | 8 | 代码结构 9 | ---------------------------------------- 10 | - include // v8接口 11 | - src // v8内部实现 12 | - arm // arm后端，将抽象语法树转换为arm指令 13 | - ia32 // ia32后端，将抽象语法树转换为ia32指令 14 | - x86 // x86后端，将抽象语法树转换为x86指令 15 | - ast // 抽象语法树的实现 16 | - d8.cc // v8的调试程序 17 | - heap // 堆实现 18 | - extension // v8的扩展机制 19 | - benchmark // 性能测试用例 20 | - build // 编译相关脚本 21 | 22 | TurboFan 23 | ---------------------------------------- 24 | TurboFan是一个包含优化过程的编译器。 25 | 26 | Ignition 27 | ---------------------------------------- 28 | Ignition 是一个解释器。 29 | 30 | 垃圾回收 31 | ---------------------------------------- 32 | V8的垃圾回收机制分为新生代和老生代。 33 | 34 | 新生代主要使用Scavenge进行管理，主要实现是Cheney算法，将内存平均分为两块，使用空间叫From，闲置空间叫To，新对象都先分配到From空间中，在空间快要占满时将存活对象复制到To空间中，然后清空From的内存空间，此时，调换From空间和To空间，继续进行内存分配，当满足那两个条件时对象会从新生代晋升到老生代。 35 | 36 | 老生代主要采用Mark-Sweep和Mark-Compact算法，一个是标记清除，一个是标记整理。两者不同的地方是，Mark-Sweep在垃圾回收后会产生碎片内存，而Mark-Compact在清除前会进行一步整理，将存活对象向一侧移动，随后清空边界的另一侧内存，这样空闲的内存都是连续的，但是带来的问题就是速度会慢一些。在V8中，老生代是Mark-Sweep和Mark-Compact两者共同进行管理的。 37 | 38 | 编译 39 | ---------------------------------------- 40 | :: 41 | 42 | git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git 43 | export PATH="$PATH:/path/to/depot_tools" 44 | mkdir ~/v8 45 | cd ~/v8 46 | fetch v8 47 | cd v8 48 | ./build/install-build-deps.sh 49 | tools/dev/gm.py x64.release 50 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Byte-compiled / optimized / DLL files 2 | __pycache__/ 3 | *.py[cod] 4 | *$py.class 5 | 6 | # C extensions 7 | *.so 8 | 9 | # Distribution / packaging 10 | .Python 11 | env/ 12 | build/ 13 | develop-eggs/ 14 | dist/ 15 | downloads/ 16 | eggs/ 17 | .eggs/ 18 | lib/ 19 | lib64/ 20 | parts/ 21 | sdist/ 22 | var/ 23 | wheels/ 24 | *.egg-info/ 25 | .installed.cfg 26 | *.egg 27 | 28 | # PyInstaller 29 | # Usually these files are written by a python script from a template 30 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 31 | *.manifest 32 | *.spec 33 | 34 | # Installer logs 35 | pip-log.txt 36 | pip-delete-this-directory.txt 37 | 38 | # Unit test / coverage reports 39 | htmlcov/ 40 | .tox/ 41 | .coverage 42 | .coverage.* 43 | .cache 44 | nosetests.xml 45 | coverage.xml 46 | *.cover 47 | .hypothesis/ 48 | 49 | # Translations 50 | *.mo 51 | *.pot 52 | 53 | # Django stuff: 54 | *.log 55 | local_settings.py 56 | 57 | # Flask stuff: 58 | instance/ 59 | .webassets-cache 60 | 61 | # Scrapy stuff: 62 | .scrapy 63 | 64 | # Sphinx documentation 65 | docs/_build/ 66 | 67 | # PyBuilder 68 | target/ 69 | 70 | # Jupyter Notebook 71 | .ipynb_checkpoints 72 | 73 | # pyenv 74 | .python-version 75 | 76 | # celery beat schedule file 77 | celerybeat-schedule 78 | 79 | # SageMath parsed files 80 | *.sage.py 81 | 82 | # dotenv 83 | .env 84 | 85 | # virtualenv 86 | .venv 87 | venv/ 88 | ENV/ 89 | 90 | # Spyder project settings 91 | .spyderproject 92 | .spyproject 93 | 94 | # Rope project settings 95 | .ropeproject 96 | 97 | # mkdocs documentation 98 | /site 99 | 100 | # mypy 101 | .mypy_cache/ 102 | -------------------------------------------------------------------------------- /source/ref/vuln.rst: -------------------------------------------------------------------------------- 1 | 漏洞相关 2 | ================================ 3 | - `js-vuln `_ 4 | - `cve-2018-4192 and cve-2018-4262 `_ 5 | - `cve-2016-0189 `_ 6 | - `CVE-2018-4121 Safari Wasm Exploit `_ 7 | - `Enforcement of Bounds Checks in Native JIT Code `_ 8 | - `The Advanced Exploitation of 64-bit Edge Browser Use-After-Free Vulnerability on Windows 10 `_ 9 | - `From Assembly to JavaScript and Back `_ 10 | - `awesome browser exploit `_ 11 | - `pwnjs `_ 12 | - `Write-up for CVE-2018-8495 `_ 13 | - `blackhat us 18 attacking client side jit compilers `_ 14 | - `WebExtension security Part1 `_ 15 | - `cve-2018-8629 `_ 16 | - `Introduction to SpiderMonkey exploitation `_ 17 | - `webkit bugmap `_ 18 | -------------------------------------------------------------------------------- /source/intro/vultype.rst: -------------------------------------------------------------------------------- 1 | 浏览器漏洞类型 2 | ================================================== 3 | 4 | 简介 5 | -------------------------------------------------- 6 | 一般漏洞指通过软件缺陷触发的，会有损完整性、可用性、机密性三者中一项的问题。在浏览器研究中，一般涉及到所有会影响到用户信息安全的问题，例如页面伪造、钓鱼、下载文件病毒检查、广告弹窗、不良内容过滤、用户设置保护等问题。通常可以分为以下几种类型。 7 | 8 | 信息泄漏漏洞 9 | -------------------------------------------------- 10 | 旧版本的IE浏览器可以用 JavaScript 检测是否存在某文件。这样会泄漏用户是否安装了杀毒软件，以便恶意代码进行下一步操作。 11 | 有些信息泄漏漏洞会泄漏内存的信息，攻击者可能使用泄漏的信息来绕过操作系统的保护机制，如ASLR、DEP等。 12 | 还有一类信息泄漏漏洞：UXSS(通用跨站脚本漏洞)。这种跨越域隔离策略的漏洞，可以在后台打开其它域的网页，或者获取其他域的cookie。 13 | 14 | 内存破坏漏洞 15 | -------------------------------------------------- 16 | 内存破坏漏洞又可以细分为释放后重用漏洞(UAF)，越界读写漏洞，类型混淆漏洞，其中越界读写漏洞也能用来泄漏内存信息。该类型的漏洞可能由DOM渲染、JavaScript引擎、PDF解析、图片解析、音频解析等多个模块触发。一些复杂的三方库存在的问题也可能导致浏览器被攻破。 17 | 18 | 沙箱逃逸漏洞 19 | -------------------------------------------------- 20 | 为了防止RCE漏洞影响主机，部分浏览器提供了沙箱机制，而一些漏洞可以使得沙箱机制被逃逸。 21 | 22 | 扩展和插件漏洞 23 | -------------------------------------------------- 24 | 某些浏览器插件或者扩展会存在一些安全问题，如果浏览器没有做好隔离，则可能利用其漏洞对主机进行攻击。 25 | 26 | UI欺骗 27 | -------------------------------------------------- 28 | 浏览器UI上最容易发生的攻击就是用户界面欺骗，也就是UI Spoof。通常UI Spoof被用来进行网络钓鱼攻击使用。网络钓鱼是社会工程学中用于欺骗用户，进而获取用户的敏感信息的一种攻击手段，通常使用伪造网站等方法，诱使用户从视觉感官上相信其是合法真实的，当用户在浏览器中进行操作后，敏感信息就有可能被攻击者获取到。 29 | 30 | uXSS 31 | -------------------------------------------------- 32 | 通用跨站脚本(Universal Cross-Site Scripting, UXSS)是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。和普通XSS的重要区别是，uXSS可以读取所有会话的Cookie信息。 33 | 34 | XSS Auditor Bypass 35 | -------------------------------------------------- 36 | 部分浏览器提供了XSS Auditor的功能，但是为了不影响网站的正常使用，往往使用黑名单的方式来实现，故可能存在Bypass。 37 | 38 | 特权域 XSS + 特权域 API 39 | -------------------------------------------------- 40 | 比如搜狗浏览器浏览网页可下载任意文件到任意位置，重启之后，电脑可能被完全控制。百度浏览器可静默安装插件，且存在目录穿越漏洞。解压缩到启动目录，重启之后，电脑被完全控制。 41 | -------------------------------------------------------------------------------- /source/browsers/edge.rst: -------------------------------------------------------------------------------- 1 | Edge 2 | ================================================== 3 | 4 | 进程架构 5 | -------------------------------------------------- 6 | 在较早的版本，Edge由 ``MicrosoftEdge.exe`` ``MicrosoftEdgeCP.exe`` 两个进程组成。而后Edge使用UWP架构，之后其进程主要由 ``RuntimeBroker.exe`` 和其他进程组成，其中 ``RuntimeBroker.exe`` 为中等完整性级别，其他进程都在 ``AppContainer`` 中以低完整性级别运行。 7 | 8 | 当前版本的Edge运行的进程如下： 9 | 10 | - MicrosoftEdge.exe 11 | - mediumintegrity 12 | - 主进程 13 | - MicrosoftEdgeCP.exe (Web) 14 | - AppContainer 15 | - Web内容处理 16 | - MicrosoftEdgeCP.exe (UI) 17 | - AppContainer 18 | - 新Tab的内容处理 19 | - MicrosoftEdgeCP.exe (Extensions) 20 | - AppContainer 21 | - 扩展处理 22 | - MicrosoftEdgeCP.exe(Settings) 23 | - AppContainer 24 | - 设置相关处理 25 | - MicrosoftEdgeCP.exe(Flash) 26 | - AppContainer 27 | - Flash处理 28 | - MicrosoftEdgeCP.exe(OOPJS) 29 | - AppContainer 30 | - JIT编译处理 31 | - browser_broker.exe 32 | - mediumintegrity 33 | - Broker进程 34 | - RuntimeBroker.exe 35 | - mediumintegrity 36 | - 权限管理 37 | 38 | 完整性级别 39 | -------------------------------------------------- 40 | - 高等完整性级别是管理员权限 41 | - 中等完整性级别是普通用户运行进程的权限 42 | - 低完整性级别有以下的限制 43 | - 大多数的Windows消息和进程Hook都被UIPI(User Interface Privilege Isolation)限制 44 | - 开进程和CreateRemoteThread被mandatory标签禁止 45 | - 不允许以写权限打开共享内存 46 | - 使用比其完整性级别高的进程创建的对象 47 | - 绑定到运行中的Component Object Model服务 48 | - 低完整性级别可以操作 49 | - 剪贴板 50 | - Remote Procedure Calls (RPC) 51 | - Sockets 52 | - 被更高级别完整性进程设置为允许的Window Message 53 | - 被更高级别完整性进程设置为允许的共享内存 54 | - 被更高级别完整性进程设置为允许的COM 55 | - 被更高级别完整性进程设置为允许的命名管道 56 | - 不信任级别几乎所有涉及到权限的操作都不被允许 57 | 58 | AppContainer 59 | -------------------------------------------------- 60 | AppContainer是Windows提出的进程隔离机制。通过将应用程序与不需要的资源和其他应用程序隔离，可以最大限度地减少恶意操纵的机会 基于最小权限授予访问权限可防止应用程序和用户访问超出其权限的资源。 61 | 62 | 其提供了用户凭证、设备、文件、网络、进程等的隔离。 63 | -------------------------------------------------------------------------------- /source/fuzz.rst: -------------------------------------------------------------------------------- 1 | Fuzz方法 2 | ======================================== 3 | 4 | 简介 5 | ---------------------------------------- 6 | Fuzz又称模糊测试，是一种侧重于发现软件安全漏洞的方法。典型的Fuzz测试过程是通过自动的或半自动的方法，反复驱动目标软件运行，并为其提供特别构造的输入数据，同时监控软件运行的异常，进而根据异常结果及输入数据查找软件的安全漏洞。谷歌、微软、思科等公司都使用模糊测试作为软件安全开发流程的一部分。 7 | 8 | 白盒Fuzz 9 | ---------------------------------------- 10 | 11 | 简介 12 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13 | 白盒Fuzz在测试之前通常会先对应用进行分析，获取一定的信息来辅助其创建的输入能在应用程序中发现崩溃。 14 | 15 | 其通常遇到的问题是一个应用程序一般有有许多分支，然后形成许多可能的执行流。不过如果有了很大的测试空间，就有可能创建几乎无限的输入来遍历所有的执行流。一般白盒Fuzz会试图创造在更少的输入的同时来尽量覆盖更多的路径。目前也有一些研究取得了成果，比如CRAX[1-2]就用符号执行的方式完成了一个白盒浏览器漏洞Fuzz工具。 16 | 17 | 但是由于执行流程过多和复杂的约束，白盒Fuzz在应用程序中可能并不精确。 此外，白盒Fuzz分析应用程序需要比较多的时间，所以浏览器Fuzz一般仍以黑盒Fuzz为主。 18 | 19 | 符号执行 20 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 21 | 符号执行是白盒Fuzz的一个常用技术。其关键思想就是，把输入变为符号值，那么程序计算的输出值就是一个符号输入值的函数。这个符号化的过程在文章[1-9]中已有简要阐述，简而言之，就是一个程序执行的路径通常是true和false条件的序列，这些条件是在分支语句处产生的。 22 | 23 | 符号执行要解决的问题主要是路径选择、约束求解、内存建模、处理并发这几个方面。 24 | 25 | 黑盒Fuzz 26 | ---------------------------------------- 27 | 黑盒Fuzz是一个有效和找到漏洞的简单方法，和白盒不同的是，黑盒Fuzz不关心程序执行的状态，认为程序是一个黑盒。其直接产生输入然后尝试找到结果。黑盒Fuzz也常被称为是数据驱动的Fuzz，大部分传统Fuzzer都是黑盒的。 28 | 29 | 灰盒Fuzz 30 | ---------------------------------------- 31 | 在白盒和黑盒之后，一些研究者提出了灰盒Fuzz，结合黑盒和白盒两种方式进行Fuzz。使用黑盒Fuzz进行执行，也一定程度上使用轻量的白盒方式为黑盒提供反馈。比单纯的白盒Fuzz更轻量级，比黑盒Fuzz更有效率。 32 | 33 | 生成策略 34 | ---------------------------------------- 35 | 36 | Mutation-Based Fuzz 37 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 38 | 在Mutation-Based Fuzz中，一般会提供一个到多个有效的样本，基于变异Fuzz方式对这些样本进行变异。常用的方式有字节级跳变、块级别的替换、删除、增加、重复、基于字典的变异等。 39 | 40 | 对浏览器的模糊测试而言，为了达到更好的效果，目前的变异方式有基于源代码的变异、基于AST的变异、基于字节码的变异等。 41 | 42 | 相对来说，这种Fuzz方式比较好实现，而且几乎不需要任何的先验知识，只要有一个或几个构造好的样本即可。但是相对来说，这种Fuzz方式也更依赖于给定的样本，如果样本触发的代码覆盖率不高，那么这种方式的覆盖率一般也不会高。 43 | 44 | Genertion-Based Fuzz 45 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46 | Genertion-Based Fuzz通常使用的方法有基于随机字符的生成、基于语法结构的生成等。相对Mutation-Based Fuzz，直接生成样本的方式覆盖率会更高。但是相对的，这种方式也需要更多的种子样本，对样本的依赖性也更强。 47 | 48 | Hybrid Fuzz 49 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 50 | 考虑到Genertion-Based和Mutation-Based的优缺点，那么另一种方式就是结合两种模式共同进行Fuzz，生成随机样本之后再进行相应的变换，以获得更好的Fuzz效率。 51 | 52 | 导向策略 53 | ---------------------------------------- 54 | 55 | 覆盖率导向 56 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 57 | 在生成或变异的过程中，为了能更有效的Fuzz，通常会使用导向性的策略，比如基于覆盖率的导向性策略等。 58 | 59 | 导向性Fuzz最开始由AFL提出，其对样本执行后的覆盖率进行统计，找到变异后对覆盖率影响较大的字节，更多的对其进行测试，来实现更高效的变异。 60 | 61 | 而后逐渐引入了基于机器学习的方式，比如基于随机下降算法的覆盖率导向方式、基于进化算法的覆盖率导向方式等来实现更高效的导向。 62 | 63 | Patch Based 64 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 65 | 除了覆盖率导向，也有基于补丁分析的模糊测试方式。 66 | -------------------------------------------------------------------------------- /source/ref/blog.rst: -------------------------------------------------------------------------------- 1 | Blog or Talks 2 | ================================ 3 | - `浏览器fuzz工具 `_ 4 | - `浏览器fuzz框架 `_ 5 | - `nduja `_ 6 | - `Morph `_ 7 | - `R Valotta `_ 8 | - `符号执行入门 `_ 9 | - `blueclosure blog `_ 10 | - `MongoDBs fuzzer `_ 11 | - `JavaScript engine fundamentals optimizing prototypes `_ 12 | - `深入理解Webkit `_ 13 | - `Timeline of Web Browsers `_ 14 | - `Browser UI Security `_ 15 | - `life of a pixel `_ 16 | - `Inline Caching in JavaScriptCore `_ 17 | - `webidl `_ 18 | - `The Great DOM Fuzz-off of 2017 `_ 19 | - `Finding and Exploiting Safari Bugs using Publicly Available Tools `_ 20 | - `wabt `_ 21 | - `ecma262 `_ 22 | - `strengthening microsoft edge sandbox `_ 23 | - `breaking the local browser sandbox `_ 24 | - `Forshaw Digging For IE11 Sandbox Escapes `_ 25 | - `digging into turbofan jit `_ 26 | - `liftoff `_ 27 | - `fuzzing binaries without execve `_ 28 | - `fuzzingbook `_ 29 | - `浏览器的工作原理：新式网络浏览器幕后揭秘 `_ 30 | - `黄正 如何用正确姿势挖掘浏览器漏洞 `_ 31 | -------------------------------------------------------------------------------- /source/ref/paper.rst: -------------------------------------------------------------------------------- 1 | 参考文献 2 | ================================================== 3 | - ``IEEE 2016`` ``Black Box`` Lin Y D, Liao F Z, Huang S K, et al. Browser fuzzing by scheduled mutation and generation of document object models[C]// International Carnahan Conference on Security Technology. IEEE, 2016:1-6. 4 | - ``IEEE 2012`` ``White Box`` Huang S K, Huang M H, Huang P Y, et al. CRAX: Software Crash Analysis for Automatic Exploit Generation by Modeling Attacks as Symbolic Continuations[C]// IEEE Sixth International Conference on Software Security and Reliability. IEEE, 2012:78-87. 5 | - ``Usenix 2014`` ``Seed Generation`` Rebert A, Sang K C, Grieco G, et al. Optimizing seed selection for fuzzing[C]// Usenix Conference on Security Symposium. USENIX Association, 2014:861-875. 6 | - ``ACM 2013`` ``Black Box`` Woo M, Sang K C, Gottlieb S, et al. Scheduling black-box mutational fuzzing[C]// ACM Sigsac Conference on Computer & Communications Security. ACM, 2013:511-522. 7 | - 钱文祥. 白帽子讲浏览器安全[M]. 电子工业出版社, 2016. 8 | - ``ACM 2013`` Paige M. The tangled web: a guide to securing modern web applications by Michal Zalewski[M]. ACM, 2013. 9 | - ``IEEE 2013`` ``Black Box`` Guo T, Zhang P, Wang X, et al. GramFuzz: Fuzzing testing of web browsers based on grammar analysis and structural mutation[C]// Second International Conference on Informatics and Applications. IEEE, 2013:212-215. 10 | - ``ACM 2013`` ``White Box`` Avgerinos T, Sang K C, Rebert A, et al. Automatic exploit generation[J]. Communications of the Acm, 2014, 57(2):74-84. 11 | - ``IEEE 2010`` ``Symbolic Execution`` Schwartz E J, Avgerinos T, Brumley D. All You Ever Wanted to Know about Dynamic Taint Analysis and Forward Symbolic Execution (but Might Have Been Afraid to Ask)[C]// Security and Privacy. IEEE, 2010:317-331. 12 | - ``ACM 2013`` ``Symbolic Execution`` Cadar C, Sen K. Symbolic execution for software testing: three decades later[J]. Communications of the Acm, 2013, 56(2):82-90. 13 | - ``Fuzz PNG`` Miller C, Peterson Z N J. Analysis of mutation and generation-based fuzzing[J]. Independent Security Evaluators, Tech. Rep, 2007. 14 | - ``IEEE 2005`` Oehlert P. Violating Assumptions with Fuzzing[J]. IEEE Security & Privacy, 2005, 3(2):58-62. 15 | - ``Usenix 2012`` Holler C, Herzig K, Zeller A. Fuzzing with Code Fragments[J]. Proc Usenix Security, 2012:445--458. 16 | - ``IEEE CCIS2012`` ``Fuzz BMP`` Hou Y, Tao G, Shi Z, et al. Research on Android browser fuzzing based on bitmap structure[M]. 2013. 17 | - ``ACM 2017`` Guo R. MongoDB's JavaScript Fuzzer[M]. ACM, 2017. 18 | - ``Usenix 2018`` Yun I, Lee S, Xu M, et al. QSYM: A Practical Concolic Execution Engine Tailored for Hybrid Fuzzing[C]//27th USENIX Security Symposium (USENIX Security 18). USENIX Association, 2018. 19 | -------------------------------------------------------------------------------- /source/fuzzers/implementation.rst: -------------------------------------------------------------------------------- 1 | Fuzzer实现 2 | ================================================== 3 | 4 | 综述 5 | -------------------------------------------------- 6 | 7 | 按功能分类 8 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 9 | 总的来说，浏览器Fuzz框架要实现的主要功能是随机样本的生成、浏览器进程监控、Crash样本保存。而各个框架则在完成基本功能的基础上实现分布式调度、自定义fuzz策略、样本精简、分析crash等特性。 10 | 11 | 如果要分类的话，浏览器fuzz工具大概可以分为框架类、策略类以及综合类。策略类工具制定了一系列新建、修改、删除DOM元素的规则。通过生成随机样本的方式，产生不同的样本来测试浏览器是否产生异常。而框架类工具则是提供了启动并监控浏览器进程、打开或记录异常样本等功能，将策略类工具承载起来的Fuzzing平台。 12 | 13 | 框架类比较有代表性的是BFuzzer、grinder、cross_fuzz、x-fuzzer等，这类工具提供了fuzz的基本功能，但是没有涉及样本生成的策略。而策略类工具中比较有代表性的是nduja和fileja[3-5]，这两个工具是由Valotta完成的浏览器fuzz样本生成脚本，有着比较丰富的生成规则，但是并没有实现自动化的测试等功能。综合类则综合了两类的特点，完成了两种功能，比较有代表性的是clusterfuzz、funfuzz、chromefuzzer、ajaxdemolisher、lithium等。 14 | 15 | 这些工具基本都通过javascript脚本进行fuzz操作，同时通过hook函数、localStorage本地存储等技术手段动态记录fuzz操作日志，捕获到异常后再根据记录日志进行还原。 16 | 17 | 按攻击面分类 18 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 19 | 另外一种分类的思路是按攻击面分类，常见的fuzzer都是针对DOM进行fuzz，但是也有一些fuzz工具专注于其他的攻击面。比如针对ActiveX进行fuzz的axman，另外也有一些针对JavaScript脚本[2-8]、CSS、图片[1-11][1-14]、PDF、SVG、Flash、浏览器扩展、插件等进行fuzz的工具。 20 | 21 | 运行 22 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 23 | 一般运行一个测试样例的思路为，生成样本，发送至服务器端，浏览器访问服务器端获取样本，加载并执行样本。 24 | 25 | 随机样本的生成 26 | -------------------------------------------------- 27 | 随机样本生成的好坏，直接决定了该工具能否挖掘出有价值的漏洞。目前纯Fuzz方法中，比较流行的就是根据目标文件格式生成针对性样本，效果也比较理想。以HTML文档为例，诞生过很多随机生成HTML/DOM元素的Browser Fuzzer。 28 | 29 | 曾经盛名一时的nduja，其大致思路就是，利用JavaScript随机创建DOM元素、随机调用DOM处理函数、随机删除DOM元素等操作来完成每一次Fuzz的。 30 | 31 | 样本保存 32 | -------------------------------------------------- 33 | 34 | 记录随机数 35 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36 | 结合之前提到的创建DOM元素的方式，一种思路是将本次rand函数生成的所有随机数全部保存下来即可。Grinder框架就是基于这种思路，采用DLL注入的方式，劫持了JavaScript的parseFloat函数，用以记录某次样本需要记录的相关参数。 37 | 38 | 但是这样有几个缺点，一个是浏览器最新版本一般不提供symbols文件或发布symbols文件比较慢，这无疑限制了Grinder对最新浏览器的测试能力。另外一个是有时候可能是多个HTML共同导致了某个Crash，但是Grinder的日志只记录了一个HTML中的log信息，可能无法重现该类漏洞。 39 | 40 | 记录随机样本 41 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 42 | 既然记录随机值的方式存在一定的问题，那么就有了另一个思路，直接将模版中的随机元素生成后进行保存，然后浏览器再访问。这样就简化了从日志中恢复样本的流程，而且更为准确。 43 | 44 | WebSocket通信 45 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46 | 另一个方法是利用websocket，实时的把相关信息发送到服务器，在服务器端进行保存。但是这样也有一个缺点，运行的websocket相关脚本可能也会影响浏览器样本的fuzz情况。 47 | 48 | 其他样本生成方式 49 | -------------------------------------------------- 50 | 另外一种方式是根据已有的HTML样本进行变换之后生成。 51 | 样本可以来源于之前的0day，从网上获取的一些样本。 52 | 样本构造尽可能多的覆盖HTML的属性，比如css/javascript等 53 | 54 | 浏览器进程监控 55 | -------------------------------------------------- 56 | 在对浏览器的异常检测上，通常有Pydbg和Windbg等方式，这些方式都各有优劣。但pydbg对python3和x64系统软件支持都不是特别好，另外windbg具有很吸引人的!exploitable插件[2-7]，虽然某些时候给出的结论并不准确，但不失为一种对漏洞可利用性做出预判的方法。 57 | 58 | 另一个方法是，在Windows下某个进程崩溃时，通常会弹出WerFault.exe异常提示,可以根据进程列表中有无WerFault.exe作为监控浏览器是否发生Crash的依据。另外，将Windbg的命令行版cdb.exe设置为默认即时调试器。当发生crash时自动调用该调试器，并做下记录，也是一个可行的方法。 59 | 60 | 浏览器fuzz缺点 61 | -------------------------------------------------- 62 | 很多浏览器fuzz工具每运行一个测试用例都会重启待测浏览器进程，因为浏览器重启在运行一个测试用例过程中耗时占比较大，进而导致fuzz效率不高。 63 | -------------------------------------------------------------------------------- /source/browsers/chakra.rst: -------------------------------------------------------------------------------- 1 | ChakraCore 2 | ================================ 3 | 4 | 简介 5 | -------------------------------- 6 | ChakraCore是一个完整的JavaScript虚拟机，它拥有着和Chakra几乎相同的功能与特性。但在它们之间有两个不同点： 7 | 8 | - ChakraCore没有公开Chakra与浏览器/UWP之间的私有绑定部分 9 | - Chakra使用一套基于COM的诊断API，而ChakraCore使用一套基于JSON的诊断API。这套API是平台无关的，可用于之后不同实现之间的操作。 10 | 11 | |framework| 12 | 13 | 执行流程 14 | -------------------------------- 15 | ChakraCore支持一种多级架构，包括： 16 | 17 | - (1)用来快速启动的解释器 18 | - (2)用来产生高度优化的代码的并行JIT编译器 19 | - (3)一个并行的后台GC来降低停顿，提高响应速度 20 | 21 | 一旦JavaScript开始运行，ChakraCore首先进行一次快速的语法解析来报告语法错误。接下来ChakraCore的每个函数会按需执行(as-needed-per-function)。 22 | 23 | 只要有可能，ChakraCore就会延迟那些暂时不需要的函数的语法解析和AST的生成，并且将JIT编译和垃圾回收等工作推出主线程。这样做的目的是为了有效利用硬件资源去保证响应速度。 24 | 25 | 当一个函数第一次执行时，ChakraCore的parser将产生一个AST来代表这个函数的源码，随后AST会被翻译为字节码，这些字节码将由ChakraCore解释器直接执行。在解释执行期间解释器会收集一些程序信息，如类型信息、调用次数，这些信息会被用来帮助JIT编译器生成高度优化的机器码。 26 | 27 | 当ChakraCore在解释器中发现一个函数或者循环(loop-body)被多次执行时，会将其送入后台JIT编译队列为这个函数生成优化的代码。一旦这些优化代码准备就绪，ChakraCore就会替换函数和循环的入口到这些新代码，之后的执行将远快于之前的解释执行。 28 | 29 | ChakraCore的后台JIT编译器借助解释器生成的profile来推断可能出现的模式，从而生成高度优化的本地代码。当得到JavaScript代码的某些动态特性后，如果代码行为打破了基于profile的预测，编译出的代码将会被bailout到解释器，进行字节码解释执行以获取更多的profile数据。 30 | 31 | 为了平衡JIT编译时间与内存占用，ChakraCore并不在一个函数每次释出时编译它，而是利用缓存下来的编译结果直到释出次数达到一定的门槛，之后才会迫使代码重新被JIT编译并且抛弃旧的编译结果。 32 | 33 | |pipeline| 34 | 35 | JIT编译器 36 | -------------------------------- 37 | ChakraCore拥有两级JIT编译器。在同一个后台线程中，ChakraCore有一个完全JIT编译器(Full JIT Compiler)用来产生高度优化的代码；还有一个简单JIT编译器(Simple JIT Compiler)，这是一个有较少优化版本的完全JIT编译器。 38 | 39 | 在执行时，ChkaraCore首先将解释执行的函数换入简单JIT编译器，然后才是完全JIT编译。 40 | 41 | 在大多数情况下，简单JIT编译耗时少于完全JIT编译，所以相比单级JIT，这种架构有助于更快启动app。 42 | 43 | 多一个简单JIT的另一个优势是，当"释出"发生时，函数的执行可以更快地从解释切换到简单JIT编译，直到完全JIT编译的代码就绪。简单JIT编译的代码执行管线依然继续收集profile信息以供完全JIT编译器使用。 44 | 45 | 无论何时，只要有潜在的未被利用的硬件资源，ChakraCore也可为后台JIT编译器产生多个并行线程。存在多个后台JIT编译线程时，ChakraCore的简单JIT编译和完全JIT编译的工作都会被分摊到多个编译线程上进行跨线程编译。这有助于在总体上减少JIT编译延迟。 46 | 47 | 垃圾回收 48 | -------------------------------- 49 | ChakraCore拥有一个分代式标记清扫垃圾回收器，它支持并行、部分回收。当完全并行GC被初始化，ChakraCore的后台GC会进行一个初始标记阶段，然后重新扫描(rescan)来找出在这个初始标记阶段被主线程修改的对象，随后再运行第二个标记阶段来标记重新扫描时被修改的对象。当第二个标记阶段扫描结束后，主线程暂停执行并启动最终的重新扫描(final rescan)，之后最终的标记阶段(final marking pass)会被分解到主线程和已经在执行的GC线程。最后清扫阶段由后台GC线程完成，并且将无法到达的(unreachable)的对象重新加入分配池。 50 | 51 | |gc| 52 | 53 | 代码结构 54 | -------------------------------- 55 | :: 56 | 57 | . 58 | ├─bin 生成可执行文件的工程，比如ChakraCore.dll 59 | ├─Build 各个平台下的makefile或项目工程 60 | ├─jenkins 给jenkins使用的检查和编译的脚本 61 | ├─lib ChakraCore主要实现 62 | │ ├─Backend JIT的实现 63 | │ ├─Common ChakraCore的基础库 64 | │ │ ├─Codex 编码转换，比如UTF-8 65 | │ │ ├─Common 基础类，比较杂，比如和整型相关的数学计算，时间处理等 66 | │ │ ├─Core 比较杂，和ChakraCore的功能相关的代码，比如配置文件等 67 | │ │ ├─DataStructures 基础数据结构，比如数组，链表，HashMap等 68 | │ │ ├─Exceptions 常用异常 69 | │ │ ├─Memory 内存管理，GC 70 | │ │ ├─PlaceHolder ... 71 | │ │ ├─PlatformAgnostic 和平台相关的信息的封装，但这里只有定义 72 | │ │ └─Util ... 73 | │ ├─JITClient 进程外JIT的客户端 74 | │ ├─JITIDL 进程外JIT的协议，IDL定义 75 | │ ├─JITServer 进程外JIT的服务端 76 | │ ├─Jsrt Jsrt API，主要用于将ChakraCore内部结构合理的暴露出来 77 | │ ├─Parser JavaScript Parser 78 | │ ├─Runtime Runtime，ChakraCore最关键的部分之一 79 | │ │ ├─Base Runtime中的顶层数据结构 80 | │ │ ├─ByteCode ByteCode相关的实现 81 | │ │ ├─Debug 用于支持调试的类 82 | │ │ ├─Language 比较杂，和JavaScript语言相关但又不易归类的部分 83 | │ │ ├─Library JavaScript对象模型的实现，bool/int/map/regex/promise等 84 | │ │ ├─Math 计算相关，加减乘除等 85 | │ │ ├─PlatformAgnostic 平台相关的实现 86 | │ │ └─Types 用来实现对象模型的基础类型，比如抽象的Type和RecylableObject 87 | │ └─WasmReader WebAssembly加载器 88 | ├─manifests 用于定义ETW Events的manifest 89 | ├─pal 一个C标准库的实现，可以使用USING_PAL_STDLIB宏来启用 90 | ├─test 测试用例 91 | └─tools 一些小工具 92 | 93 | 94 | 95 | 96 | .. |framework| image:: ../images/chakra/framework.png 97 | .. |pipeline| image:: ../images/chakra/pipeline.png 98 | .. |gc| image:: ../images/chakra/gc.png 99 | -------------------------------------------------------------------------------- /source/browsers/chrome.rst: -------------------------------------------------------------------------------- 1 | Chrome 2 | ================================================== 3 | 4 | 进程架构 5 | -------------------------------------------------- 6 | Chrome涉及到多个进程，在各个进程间都设置了不同的完整性程度 7 | 8 | + 主进程 9 | + 主框架部分，管理子进程 10 | + 管理地址栏、书签、前进/后退按钮等 11 | + 处理浏览器的不可见任务，如网络请求和本地文件访问等 12 | + Medium Integrity Level 13 | + 渲染进程 14 | + 渲染和处理获取到的Web内容 15 | + Untrusted Integrity Level 16 | + GPU进程 17 | + 和显卡交互 18 | + Low Integrity Level 19 | + 扩展进程 20 | + 运行扩展代码 21 | + Untrusted Integrity Level 22 | + 插件进程 23 | + 运行插件代码 24 | + Untrusted Integrity Level 25 | + Utility进程 26 | + 运行特定任务 27 | + Untrusted Integrity Level 28 | 29 | JavaScript引擎 30 | -------------------------------------------------- 31 | V8是Chrome的JavaScript语言处理程序（VM）。其引擎由TurboFan、Ignition和Liftoff组成。其中Turbofan是其优化编译器，Ignition则是其解释器，Liftoff是WebAssembly的代码生成器。 32 | 33 | 渲染与IPC 34 | -------------------------------------------------- 35 | 在Chrome中，把进程分隔开来，来保护整个进程不受渲染引擎的一些bug干扰。也限制了渲染引擎对整个系统的访问。总的来说，做了内存保护和访问控制的工作。 36 | 37 | Chrome用了blink，一个开源的layout engine来解析HTML的layout。 38 | 39 | |framework| 40 | 41 | 渲染进程管理 42 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 43 | 每个渲染进程都有一个对应的全局RenderProcess对象管理和浏览器进程之间的通信，并保存一些全局状态。浏览器也相应的保存了一个RenderProcessHost来管理浏览状态并与渲染进程通信。他们之间通信使用了Chromium的IPC system。 44 | 45 | 视图管理 46 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 47 | 每一个渲染进程都有由RenderProcess管理的和浏览器的标签页对应的一个或多个RenderView对象。相应的RenderProcessHost都有一个RenderViewHost和正在渲染的view相对应。 48 | 49 | 每个view都有一个ID，用来唯一标识。ID在渲染进程中是唯一的，但是在浏览器中是不唯一，所以确定一个view需要view ID和RenderProcessHost。 50 | 51 | 浏览器和特定标签页之间的通信是通过RenderViewHost对象完成的，RenderViewHost知道如何通过RenderProcessHost传递信息给RenderProcess和RenderView 52 | 53 | 模块和接口 54 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 55 | 在渲染进程中: 56 | + RenderProcess保持着和相应RenderProcessHost之间的IPC通信。每一个渲染进程都有一个RenderProcess对象。这是浏览器和渲染模块通信的细节。 57 | + RenderView和RenderViewHost、webkit的嵌入层通信。这个对象表示选项卡或弹出窗口中的一个网页的内容 58 | 59 | 在浏览器进程中: 60 | + Browser对象代表了最高level的浏览器窗口 61 | + RenderProcessHost对象表示浏览器端的单个浏览器<-->渲染器的IPC连接。 在每个渲染过程的浏览器进程中有一个RenderProcessHost。 62 | + RenderViewHost对象封装了与远程RenderView的通信，RenderWidgetHost在浏览器中处理RenderWidget的输入和渲染 63 | 64 | 共享渲染过程 65 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 66 | 通常，每个新的窗口或选项卡都会在一个新的过程中打开。浏览器将产生一个新的进程，并指示它创建一个单独的RenderView。 67 | 68 | 有时需要或希望在标签页或窗口之间共享渲染过程。一个Web应用程序打开一个新的窗口，它期望同步进行通信，例如在JavaScript中使用window.open。在这种情况下，当我们创建一个新的窗口或选项卡时，我们需要重新使用窗口打开的进程。如果进程总数太大，或者用户已经有进程打开导航到该域，那么我们还有策略将新的选项卡分配给现有进程。这些策略在过程模型中有所描述。 69 | 70 | 检测渲染器的Crash或者错误行为 71 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 72 | 每个IPC连接到一个浏览器进程监视进程句柄。如果这些句柄发出信号，则渲染过程已经崩溃，并且通知了标签页。现在，我们显示一个“sad tab”屏幕，通知用户渲染器已经崩溃。可以通过按重新加载按钮或启动新的导航来重新加载页面。当这种情况发生时，我们注意到没有进程并创建一个新进程。 73 | 74 | 沙盒渲染器 75 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 76 | 鉴于渲染器在单独的进程中运行，我们有机会通过沙箱限制其对系统资源的访问。例如，我们可以确保渲染器对网络的唯一访问是通过其父浏览器进程。同样，我们可以使用操作系统的内置权限来限制对文件系统的访问。 77 | 78 | 除了限制渲染器访问文件系统和网络之外，我们还可以对其访问用户的显示和相关对象设置限制。我们在单独的Windows“桌面”上运行每个渲染过程，该用户不可见。这样可以防止受影响的渲染器打开新窗口或捕获击键。 79 | 80 | 内存优化 81 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 82 | 给定的渲染器在单独的进程中运行，将隐藏的选项卡视为较低优先级变得很简单。通常，Windows上的最小化进程将其内存自动放入“可用内存”池中。在内存不足的情况下，Windows会将内存交换到磁盘，然后才能更换优先级的内存，从而有助于保持用户可见程序的响应。我们可以将这个相同的原则应用于隐藏的标签当渲染过程没有顶级选项卡时，我们可以释放该进程的“工作集”大小作为系统的提示，以便在必要时将该内存交换到磁盘。因为我们发现，当用户在两个选项卡之间切换时，减小工作集大小也会降低标签切换性能，我们逐渐释放此内存。这意味着如果用户切换回最近使用的选项卡，则该选项卡的内存比较少使用的选项卡更有可能被分页。具有足够内存来运行所有程序的用户根本不会注意到这个过程：Windows只有在需要时才会实际收回这样的数据，所以当内存充足时，没有任何性能下降。 83 | 84 | 这有助于我们在低内存情况下获得更优化的内存占用。与很少使用的背景选项卡相关联的内存可以完全交换出来，而前景选项卡的数据可以完全加载到内存中。相比之下，单进程浏览器将使所有选项卡的数据随机分布在其内存中，并且不可能如此干净地分离已使用和未使用的数据，从而浪费内存和性能。 85 | 86 | 编译 87 | -------------------------------------------------- 88 | :: 89 | 90 | git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git 91 | export PATH="$PATH:/path/to/depot_tools" 92 | mkdir ~/chromium && cd ~/chromium 93 | fetch --nohooks chromium 94 | cd src 95 | ./build/install-build-deps.sh 96 | gclient runhooks 97 | gn gen out/Default 98 | 99 | 常用命令 100 | -------------------------------------------------- 101 | - ``chrome://about`` 查看所有命令 102 | - ``chrome://crashes`` 主动Crash 103 | - ``chrome://version`` 查看版本 104 | - ``chrome://flags`` 查看或关闭chrome的特性 105 | - ``chrome://dns`` DNS状态 106 | - ``chrome://net-internals`` 网络相关信息 107 | - ``chrome://quota-internals`` 磁盘相关信息 108 | 109 | .. |framework| image:: ../images/chrome-frame.png 110 | -------------------------------------------------------------------------------- /source/conf.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | # 3 | # browser_fuzz_summarize documentation build configuration file, created by 4 | # sphinx-quickstart on Mon Sep 11 09:33:53 2017. 5 | # 6 | # This file is execfile()d with the current directory set to its 7 | # containing dir. 8 | # 9 | # Note that not all possible configuration values are present in this 10 | # autogenerated file. 11 | # 12 | # All configuration values have a default; values that are commented out 13 | # serve to show the default. 14 | 15 | # If extensions (or modules to document with autodoc) are in another directory, 16 | # add these directories to sys.path here. If the directory is relative to the 17 | # documentation root, use os.path.abspath to make it absolute, like shown here. 18 | # 19 | # import os 20 | # import sys 21 | # sys.path.insert(0, os.path.abspath('.')) 22 | 23 | 24 | # -- General configuration ------------------------------------------------ 25 | 26 | # If your documentation needs a minimal Sphinx version, state it here. 27 | # 28 | # needs_sphinx = '1.0' 29 | 30 | # Add any Sphinx extension module names here, as strings. They can be 31 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom 32 | # ones. 33 | extensions = [] 34 | 35 | # Add any paths that contain templates here, relative to this directory. 36 | templates_path = ['_templates'] 37 | 38 | # The suffix(es) of source filenames. 39 | # You can specify multiple suffix as a list of string: 40 | # 41 | # source_suffix = ['.rst', '.md'] 42 | source_suffix = '.rst' 43 | 44 | # The master toctree document. 45 | master_doc = 'index' 46 | 47 | # General information about the project. 48 | project = u'浏览器模糊测试综述' 49 | copyright = u'2017-2020, lyle' 50 | author = u'lyle' 51 | 52 | # The version info for the project you're documenting, acts as replacement for 53 | # |version| and |release|, also used in various other places throughout the 54 | # built documents. 55 | # 56 | # The short X.Y version. 57 | version = u'1.0' 58 | # The full version, including alpha/beta/rc tags. 59 | release = u'1.0' 60 | 61 | # The language for content autogenerated by Sphinx. Refer to documentation 62 | # for a list of supported languages. 63 | # 64 | # This is also used if you do content translation via gettext catalogs. 65 | # Usually you set "language" from the command line for these cases. 66 | language = None 67 | 68 | # List of patterns, relative to source directory, that match files and 69 | # directories to ignore when looking for source files. 70 | # This patterns also effect to html_static_path and html_extra_path 71 | exclude_patterns = [] 72 | 73 | # The name of the Pygments (syntax highlighting) style to use. 74 | pygments_style = 'sphinx' 75 | 76 | # If true, `todo` and `todoList` produce output, else they produce nothing. 77 | todo_include_todos = False 78 | 79 | 80 | # -- Options for HTML output ---------------------------------------------- 81 | 82 | # The theme to use for HTML and HTML Help pages. See the documentation for 83 | # a list of builtin themes. 84 | # 85 | # html_theme = 'alabaster' 86 | import sphinx_rtd_theme 87 | html_theme = "sphinx_rtd_theme" 88 | html_theme_path = [sphinx_rtd_theme.get_html_theme_path()] 89 | 90 | # Theme options are theme-specific and customize the look and feel of a theme 91 | # further. For a list of options available for each theme, see the 92 | # documentation. 93 | # 94 | # html_theme_options = {} 95 | 96 | # Add any paths that contain custom static files (such as style sheets) here, 97 | # relative to this directory. They are copied after the builtin static files, 98 | # so a file named "default.css" will overwrite the builtin "default.css". 99 | html_static_path = ['_static'] 100 | 101 | 102 | # -- Options for HTMLHelp output ------------------------------------------ 103 | 104 | # Output file base name for HTML help builder. 105 | htmlhelp_basename = 'browser_fuzz_summarizedoc' 106 | 107 | 108 | # -- Options for LaTeX output --------------------------------------------- 109 | 110 | latex_elements = { 111 | # The paper size ('letterpaper' or 'a4paper'). 112 | # 113 | # 'papersize': 'letterpaper', 114 | 115 | # The font size ('10pt', '11pt' or '12pt'). 116 | # 117 | # 'pointsize': '10pt', 118 | 119 | # Additional stuff for the LaTeX preamble. 120 | # 121 | # 'preamble': '', 122 | 123 | # Latex figure (float) alignment 124 | # 125 | # 'figure_align': 'htbp', 126 | } 127 | 128 | # Grouping the document tree into LaTeX files. List of tuples 129 | # (source start file, target name, title, 130 | # author, documentclass [howto, manual, or own class]). 131 | latex_documents = [ 132 | (master_doc, 'browser_fuzz_summarize.tex', u'browser\\_fuzz\\_summarize Documentation', 133 | u'lyle', 'manual'), 134 | ] 135 | 136 | 137 | # -- Options for manual page output --------------------------------------- 138 | 139 | # One entry per manual page. List of tuples 140 | # (source start file, name, description, authors, manual section). 141 | man_pages = [ 142 | (master_doc, 'browser_fuzz_summarize', u'browser_fuzz_summarize Documentation', 143 | [author], 1) 144 | ] 145 | 146 | 147 | # -- Options for Texinfo output ------------------------------------------- 148 | 149 | # Grouping the document tree into Texinfo files. List of tuples 150 | # (source start file, target name, title, author, 151 | # dir menu entry, description, category) 152 | texinfo_documents = [ 153 | (master_doc, 'browser_fuzz_summarize', u'browser_fuzz_summarize Documentation', 154 | author, 'browser_fuzz_summarize', 'One line description of project.', 155 | 'Miscellaneous'), 156 | ] 157 | 158 | 159 | 160 | -------------------------------------------------------------------------------- /source/fuzzers/grinder.rst: -------------------------------------------------------------------------------- 1 | Grinder 2 | ================================================== 3 | 4 | 客户端配置 5 | -------------------------------------------------- 6 | 7 | - 32位系统 8 | - ``.\grinder\node\data\x86\grinder_logger.dll`` 复制到 ``c:\windows\system32\`` 9 | - 64位系统 10 | - ``.\grinder\node\data\x86\grinder_logger.dll`` 复制到 ``c:\windows\syswow64\`` 11 | - ``.\grinder\node\data\x64\grinder_logger.dll`` 复制到 ``c:\windows\system32\`` 12 | - 创建保存符号文件的目录 ``c:\symbols\`` 13 | - 编辑``config.rb`` 14 | - ``ruby grinder.rb [--config=c:\path\to\alternative\config.rb] --browser=BROWSER`` 15 | - ps: **目前grinder只支持ruby 1.9-2.0，并不支持高于2.0的版本** 16 | 17 | 18 | Node 19 | -------------------------------------------------- 20 | 21 | 主要文件说明 22 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 23 | - browser: hook相应浏览器的parseFloat 24 | 25 | + chrome.rb 26 | + firefox.rb 27 | + internetexplore.rb 28 | + safari.rb 29 | 30 | - core: 核心代码 31 | 32 | + debug 33 | 34 | * debugger.rb 浏览器所用到的debugger基类，继承自Metasm 35 | * logger.rb 记录日志 36 | + configuration.rb 配置需要的变量，检查运行环境 37 | + crypt.rb openssl 加解密库函数 38 | + debugger.rb 39 | + logging.rb 控制台输出 40 | + server.rb 运行web服务器，浏览器访问该服务器以获得样本 41 | + webstats.rb 42 | + xmlcrashlog.rb 用xml的格式记录crashlog 43 | 44 | - crashes：生成的crash样本存放的文件夹 45 | - data: 测试用的图片/pdf/js等文件，以及需要用到的dll 46 | 47 | + continue.exe => 运行在后台，点击因为crash生成的弹窗 48 | + logging.js 49 | - fuzzer：用户实现自己fuzzer的位置 50 | - lib： grinder用到的三方库主要是metasm，这是一个ruby的用来做二进制的库 51 | - source 52 | 53 | + continue.exe 源代码 54 | + logger.dll 源代码 55 | - config.rb 配置文件，若一台电脑运行多个节点时，需要多个配置文件 56 | - crypto.rb 生成密钥，加密生成的crash 57 | - grinder.rb 主文件 58 | - reduction.rb 59 | - testcase.rb 从日志中恢复样本文件 60 | 61 | 运行流程 62 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 63 | 64 | 入口文件为grinder.rb 65 | 66 | - 初始化过程 67 | - 初始化需要fuzz的浏览器 68 | - 初始化环境相关变量 69 | - 检查dll加载情况 70 | - 运行过程 71 | - 检查web server状态，若停止或未启动，则启动 72 | - 启动浏览器相应的debugger 73 | 74 | debugger运行过程 75 | 76 | - 初始化logger 77 | - hook heap 78 | - 运行目标浏览器 79 | 80 | 81 | Server 82 | -------------------------------------------------- 83 | 84 | 服务器端采用典型的PHP+MySQL的结构，设计思路是比较老的非MVC结构，总体功能比较单一，主要用来查看fuzzer节点的情况 85 | 86 | 部分文件功能说明如下 87 | 88 | - account.php 用户账户管理相关 89 | - crash.php 管理crash 90 | - crashes.php 管理crash 91 | - fuzzers.php fuzz节点状态 92 | - install.php 数据库初始化 93 | 94 | metasm 95 | -------------------------------------------------- 96 | 97 | Metasm是一个ruby实现的汇编器、反编汇器以及编译器。 98 | 99 | Fuzzer编写 100 | -------------------------------------------------- 101 | 102 | 库函数 103 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 104 | grinder提供的库函数主要有下面这些 105 | 106 | - ``rand( x )`` Pick a random number between 0 and X 107 | - ``rand_bool()`` Pick either true or false 108 | - ``rand_item( arr )`` Pick an item from an array 109 | - ``tickle(obj)`` 触发一个obj的所有属性 110 | - ``LOGGER( name )`` Logger类的构造函数 111 | 112 | SimpleExample 113 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 114 | SimpleExample.html 是grinder给出来的示例代码，展示了Fuzzer所需要的基本元素 115 | 编写logger必须的代码如下 116 | 117 | :: 118 | 119 | var logger = new LOGGER( "SimpleExample" ); 120 | logger.starting(); 121 | /* other code here */ 122 | logger.finished(); 123 | window.location.href = window.location.protocol + '//' + window.location.host + '/grinder'; 124 | 125 | 上面部分代码主要用于生成/初始化logger，以及完成fuzz之后回到grinder server 126 | 127 | fuzzer主要的代码主要还是生成随机元素的部分，继续以SimpleExample.html为例 128 | 129 | :: 130 | 131 | // 定义将要fuzz的元素 132 | var elements = [ 'div', 'input', 'textarea', 'a', 'img', 'form' ]; 133 | 134 | // 生成相关元素 135 | var elementA = rand_item( elements ); 136 | var elementB = rand_item( elements ); 137 | 138 | // 创建元素并记录，注意因为这里的fuzzer样本是随机生成的，所以需要详细的记录每一步的动作以保证可以复现 139 | logger.log( "id_0 = document.createElement( '" + elementA + "' );", "grind", 1 ); 140 | var id_0 = document.createElement( elementA ); 141 | 142 | logger.log( "document.body.appendChild( id_0 );", "grind", 1 ); 143 | document.body.appendChild( id_0 ); 144 | 145 | // 在随后的代码对之前的元素进行变化，主要是对其属性值进行变换、调用、对换等操作 146 | /* ... */ 147 | 148 | 编写 149 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 150 | 在简单看过相关的库函数和一个简单的样本之后，编写fuzzer的基础知识就已经足够了。 151 | 其必要的逻辑是在生成/修改等操作前后都调用log记录下足够的信息以便调试crash。另外就主要是设计好fuzzer种子生成的算法以及随机元素变换的算法以获取更多的crash。 152 | 153 | 154 | nduja 155 | -------------------------------------------------- 156 | 157 | SimpleExample.html更多的只是一个简单的样本，一个高效的fuzzer编写需要更精巧的思路，所以选择nduja进一步进行分析 158 | 159 | 其简单的函数调用树如下 160 | 161 | - step1 162 | + buildElementsTree1 163 | * createStyleSheet 164 | * createMultipleElement 165 | - genRandomElement 166 | - appendToRandomElement 167 | - initialize => add multiply random listener 168 | - tweakattributes1 => set attr random vaule 169 | - tweakstyle1 => set random style sheet 170 | + initialize 171 | + boom 172 | - createNodeIterator 173 | + ElementChecker 174 | * Random - case 1 175 | - createElemRange1 176 | - deleteRange1 177 | * Random - case 2 178 | - random skip / accept 179 | - createTreeWalker 180 | + ElementChecker 181 | - createTagAggregation1 182 | - createElemRange 183 | - createTxtRange 184 | - alterRange => random action 185 | + deleteContents 186 | + collapse 187 | + extractContents 188 | + surroundContents 189 | + selectNode 190 | + selectNodeContents 191 | + insertNode 192 | + setStartAfter 193 | + setStartBefore 194 | + setEndAfter 195 | + setEndBefore 196 | - spray 197 | - moveIterator 198 | + random 199 | * nextNode 200 | * previousNode 201 | + fuzzAttributes 202 | - moveTreeWalker 203 | + random 204 | * nextNode 205 | * previousNode 206 | * previousSibling 207 | * nextSibling 208 | * firstChild 209 | * lastChild 210 | * parentNode 211 | + fuzzAttributes 212 | - tagCrawler1 213 | + fuzzAttributes 214 | 215 | 可以看到，正和之前文章讲述的原因，nduja的fuzz逻辑是比较复杂的，而其fuzz的主要操作是moveIterator，moveTreeWalker。即利用节点间的联系来变换，以期找出漏洞。 216 | 217 | fileja 218 | -------------------------------------------------- 219 | 220 | 在之前提到了fileja也是基于grinder编写的fuzzer，相对于nduja，在grinder的基础上做了更多的扩展，其流程更复杂 221 | 222 | fileja除了自己编写了testcase之外，也使用了来自于W3C的testcase 223 | 224 | fileja的在函数执行之前，定义了比较多的全局变量和常量，对比较多的html元素进行了fuzz，这样能获得的crash也会比较多，定义的主要的值有下面这些 225 | 226 | - 全局参数 227 | + 元素数量 228 | + Listener数量 229 | + 是否使用svg 230 | + ... 231 | - 全局变量 232 | + websocket 233 | + xhr 234 | + ... 235 | - 全局常量 236 | + object_blacklist 237 | + interesting_vals 238 | + commands 239 | + events 240 | + mutationEvents 241 | + HTMLElements 242 | + MMLElements 243 | + SVGElements 244 | + standardAttributes 245 | + SVGCommonAttributes 246 | + SVGAttributes 247 | + ... 248 | 249 | 250 | 在定义相关的值之后，进行了fuzz，这里fuzz就更多的针对xhr，websocket和html事件，在fuzzer中各种同步和异步的事件分别触发来进行尝试 251 | 252 | + getList - get test case list from server 253 | * buildDocumentTree 254 | - random 255 | + buildFromFile 256 | - go 257 | * buildDOM 258 | * initFrame 259 | - initF => create meta, add script 260 | * initXhr => add random listener to xhr 261 | * initWs => add listener to xhr 262 | * initXhrJS => add random listener to xhr 263 | * createSupportStructures 264 | - createNodeIterator 265 | - createTreeWalker 266 | * createRanges 267 | * cycle 268 | - tick 269 | - startFuzzing 270 | + crawl_properties 271 | + call_methods 272 | + mutateDOM 273 | + CollectGarbage 274 | * reload -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | --------------------------------------------------------------------------------