在2019年初，微软正式选择了Chromium作为默认浏览器，并放弃edge的发展。并在19年4月8日，Edge正式放出了基于Chromium开发的Edge Dev浏览器，并提供了兼容Chrome Ext的配套插件管理。再加上国内的大小国产浏览器大多都是基于Chromium开发的，Chrome的插件体系越来越影响着广大的人群。
在这种背景下，Chrome Ext的安全问题也应该受到应有的关注，《从0开始入门Chrome Ext安全》就会从最基础的插件开发开始，逐步研究插件本身的恶意安全问题，恶意网页如何利用插件漏洞攻击浏览器等各种视角下的安全问题。
上篇我们主要聊了关于最基础插件开发，之后我们就要探讨关于Chrome Ext的安全性问题了，这篇文章我们主要围绕Chrome Ext的api开始，探讨在插件层面到底能对浏览器进行多少种操作。
在2019年初，微软正式选择了Chromium作为默认浏览器，并放弃edge的发展。并在19年4月8日，Edge正式放出了基于Chromium开发的Edge Dev浏览器，并提供了兼容Chrome Ext的配套插件管理。再加上国内的大小国产浏览器大多都是基于Chromium开发的，Chrome的插件体系越来越影响着广大的人群。
在这种背景下，Chrome Ext的安全问题也应该受到应有的关注，《从0开始入门Chrome Ext安全》就会从最基础的插件开发开始，逐步研究插件本身的恶意安全问题，恶意网页如何利用插件漏洞攻击浏览器等各种视角下的安全问题。
第一部分我们就主要来聊聊关于Chrome Ext的一些基础。
国外安全研究员 Andrew Danau在解决一道 CTF 题目时发现，向目标服务器 URL 发送 %0a 符号时，服务返回异常，疑似存在漏洞。
2019年10月23日，github公开漏洞相关的详情以及exp。当nginx配置不当时，会导致php-fpm远程任意代码执行。
下面我们就来一点点看看漏洞的详细分析，文章中漏洞分析部分感谢团队小伙伴@Hcamael#知道创宇404实验室
最近在研究一些Java相关的问题时候，虽然有能力读java的代码，但是从没深入了解过Java的我不免总是在各种只有Java上才有的特性上栽坑，于是忽然觉得可能需要了解一些java的漏洞，本篇文章没有太多干货，主要是自己在研究过程中的一些记录吧。
ps:在分析过程中觉得S2的官方真是傻逼，东填一下西补一下还指望能修复漏洞，真是不懂…
2019年4月15号，gitea曾爆出过一个漏洞，恰逢当时对这个漏洞比较好奇就着手去研究了一下，漏洞的描述是这样的：
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to remote code execution.
在和朋友@hammer的一同研究下，成功控制了git config的内容，但是在从git config到RCE的过程遇到了困难，就暂时搁置了，在过了几个月之后，偶然得到@Lz1y和@x1nGuang两位大佬的启发，成功复现了这个漏洞，下面我们就来仔细研究下这个问题。
在2019年7月7日结束的WCTF2019 Final上，LC/BC的成员Pavel Toporkov在分享会上介绍了一种关于redis新版本的RCE利用方式，比起以前的利用方式来说，这种利用方式更为通用，危害也更大，下面就让我们从以前的redis RCE利用方式出发，一起聊聊关于redis的利用问题。
https://2018.zeronights.ru/wp-content/uploads/materials/15-redis-post-exploitation.pdf
2019年6月11日，RIPS团队在团队博客中分享了一篇MyBB <= 1.8.20: From Stored XSS to RCE,文章中主要提到了一个Mybb18.20中存在的存储型xss以及一个后台的文件上传绕过。
其实漏洞本身来说，毕竟是需要通过XSS来触发的，哪怕是储存型XSS可以通过私信等方式隐藏，但漏洞的影响再怎么严重也有限，但漏洞点却意外的精巧，下面就让我们一起来详细聊聊看…
2019年4月11日，zdi博客公开了一篇A SERIES OF UNFORTUNATE IMAGES: DRUPAL 1-CLICK TO RCE EXPLOIT CHAIN DETAILED.
整个漏洞的各个部分没什么特别的，巧妙的是，攻击者使用了3个漏洞+几个小trick，把所有的漏洞链接起来却成了一个还不错的利用链，现在我们就来一起看看整个漏洞.
2019年3月13日， RIPS团队公开了一篇关于WordPress 5.1.1的XSS漏洞详情，标题起的很响亮，叫做wordpress csrf to rce,
https://blog.ripstech.com/2019/wordpress-csrf-to-rce/
下面我们就来详细聊聊这个漏洞。
2月20号，RIPS团队在官网公开了一篇WordPress 5.0.0 Remote Code Execution，CVE编号CVE-2019-6977，文章中主要提到在author权限账号下，可以通过修改Post Meta变量覆盖、目录穿越写文件、模板包含3个漏洞构成一个RCE漏洞。
但在原文中，作者只大致描述了漏洞原理，其中大量的漏洞细节被省略，甚至部分的利用和后端服务器也有相当的关系，所以在复现的过程中遇到了各种问题，我们花了大量的时间分析代码，最终终于完全还原了该漏洞，其中部分关键利用点用了和原文有些许差异的利用方式（原文说的太含糊其辞，无法复现）。在下面的分析中，我会尽量按照复现过程中的思考方式及流程，以便读者理解。
感谢在复现、分析过程中一起的小伙伴@Badcode，帮助我修改了很多错误的@Venenof7、@sysorem,给我提供了很多帮助:>
2018年12月3日，@L3mOn公开了一个Discuz x3.4版本的前台SSRF，通过利用一个二次跳转加上两个解析问题，可以巧妙地完成SSRF攻击链。
https://www.cnblogs.com/iamstudy/articles/discuz_x34_ssrf_1.html
在和小伙伴@Dawu复现过程中发现漏洞本身依赖多个特性，导致可利用环境各种缩减和部分条件的强依赖关系大大减小了该漏洞的危害。后面我们就来详细分析下这个漏洞。
@phith0n在代码审计小密圈二周年的时候发起了Code-Breaking Puzzles挑战赛，其中包含了php、java、js、python各种硬核的代码审计技巧。在研究复现the js的过程中，我花费了大量的精力，也逐渐找到代码审计的一些技巧，这里主要分享了5道ez题目和1道hard的the js这道题目的writeup，希望阅读本文的你可以从题目中学习到属于代码审计的思考逻辑和技巧。
这篇文章前前后后完成周期超过2个月，很幸运前段时间还是公开了，不管怎么样都希望对读者有所帮助。
在以太坊合约审计checkList中，我将以太坊合约审计中遇到的问题分为5大种，包括编码规范问题、设计缺陷问题、编码安全问题、编码设计问题、编码问题隐患。其中涵盖了超过29种会出现以太坊智能合约审计过程中遇到的问题。帮助智能合约的开发者和安全工作者快速入门智能合约安全。
本CheckList在完成过程中参考并整理兼容了各大区块链安全研究团队的研究成果，CheckList中如有不完善/错误的地方也欢迎大家提issue.
由于本文的目的主要是CheckList，所以文中不会包含太详细的漏洞/隐患信息，大部分漏洞分析在扫描报告中会有所提及。
11.18号结束的LCTF2018中有一个很有趣的智能合约题目叫做ggbank，题目的原意是考察弱随机数问题，但在题目的设定上挺有意思的，加入了一个对地址的验证，导致弱随机的难度高了许多，反倒是薅羊毛更快乐了，下面就借这个题聊聊关于薅羊毛的实战操作。
2018年11月6日，DVP上线了一场“地球OL真实盗币游戏”，其中第二题是一道智能合约题目，题目中涉及到的了一个很有趣的问题，这里拿出来详细说说看。
https://etherscan.io/address/0x5170a14aa36245a8a9698f23444045bdc4522e0a#code
HCTF2018在出题的时候其实准备了一个特别好的web题目思路，可惜赛前智能合约花了太多时间和精力，没办法只能放弃了之前的web题，在运维比赛的过程中，我发现学弟出的一些题目其实很有意思值得思考。
这次比赛为了顺应潮流，HCTF出了3道智能合约的题目，其中1道是逆向，2道是智能合约的代码审计题目。
ez2win是一份标准的合约代币，在一次审计的过程中我发现，如果某些私有函数没有加上private，可以导致任意转账，是个蛮有意思的问题，但也由于太简单，所以想给大家opcode，大家自己去逆，由于源码及其简单，逆向难度不会太大，但可惜没有一个人做出来，被迫放源码，再加上这题本来就简单，重放流量可以抄作业，有点儿可惜。
bet2loss是我在审计dice2win类源码的时候发现的问题，但出题的时候犯傻了，在出题的时候想到如果有人想用薅羊毛的方式去拿flag也挺有意思的，所以故意留了transfer接口给大家，为了能让这个地方合理，我就把发奖也改用了transfer，结果把我预期的重放漏洞给修了…
bet2loss这题在服务端用web3.py，客户端用metamask+web3.js完成，在开发过程中，还经历了metamask的一次大更新，写好的代码忽然就跑不了了，换了新的api接口…简直历经磨难。
这次比赛出题效果不理想，没想到现在的智能合约大环境有这么差，在之前wctf大师赛的时候，duca出的一道智能合约题目超复杂，上百行的合约都被从opcode逆了出来，可这次没想到没人做得到，有点儿可惜。不管智能合约以后会不会成为热点，但就目前而言，合约的安全层面还处于比较浅显的级别，对于安全从业者来说，不断走在开发前面不是一件好事吗？
下面的所有题目都布在ropsten上，其实是为了参赛者体验好一点儿，毕竟要涉及到看events和源码。有兴趣还可以去看。
经历了历时2个月伴随着HaoTian的开发，最后一份扫描总算完成了，HaoTian的雏形也基本完成了。在这篇扫描报告告一段落之后，会把之前攒的一些web思路发出来，好久没发web的文章了:>
Dice2win是目前以太坊上很火爆的区块链博彩游戏，其最大的特点就是理论上的公平性保证，每天有超过1000以太币被人们投入到这个游戏中。
dice2win的游戏非常简单，就是一个赌概率的问题。
就相当于猜硬币的正面和反面，只要你猜对了，就可以赢得相应概率的收获。
这就是一个最简单的依赖公平性的游戏合约，只要“庄家”可以保证绝对的公正，那么这个游戏就成立。
2018年9月21日，我在《以太坊合约审计 CheckList 之“以太坊智能合约编码设计问题”影响分析报告》中提到了以太坊智能合约中存在一个弱随机数问题，里面提到dice2win的合约中实现了一个很好的随机数生成方案hash-commit-reveal。
2018年10月12日，Zhiniang Peng from Qihoo 360 Core Security发表了《Not a fair game, Dice2win 公平性分析》，里面提到了关于Dice2win的3个安全问题。
在阅读文章的时候，我重新审视了Dice2win的合约代码，在第一次的阅读代码中，我着重寻找了攻击层面的问题，忽略了合约方可能会存在的问题，而且在上次的阅读中对Dice2win的执行流程有所误解，而且Dice2win也在后面的代码中迭代更新了Merkle proof功能，这里我们就重点聊聊这几个问题。
