[BJDCTF2020] web题-Cookie is so stable

如果是Jinja2的话输出应该是输出22，为什么输出22呢，'2'在python中被看作是字符串，在python中一个字符串乘上一个数字，就是将这个字符串连续输出，看下面演示。这里是Twig1.x版本（但是怎么确定是1.x版本的我没有弄明白，因此下面的payload也只适用于Twig1.x版本）最终我们的payload为。提示看一下cookie，我们在flag.php页面抓包可以看到cookie中是存在一个user参数的。确定是ssti注入，那么接下来就是确定是哪个模板了，上图。打开题目，看到如下页面。

[BJDCTF2020]Cookie is so stable(PHP|Twig|SSTI)

所以payload的大意：获取一个名字叫“cat /flag”的过滤器，找不到，自动调用刚才注册的回调函数“exec()”，把 cat /flag 作为参数传给 exec。Jinja2不能直接调用函数，需要魔术方法链，如：__class__、__mro__、__subclasses__()。1. 这里两条语句分开来写，因为它们是两个独立方法调用，Twig语法不允许一个 {{...}} 里直接写两个独立语句。2. payload用bp抓包修改，不要在页面里面直接提交，因为浏览器会自动编码，破坏语法结构。

web第45题 [BJDCTF2020]Cookie is so stable 打开靶场 访问flag页面 一个输入框 访问hint页面，查看源码 提示与cookie有关 那么在flag页面输入后抓包观察 输入后显示 登陆后抓包显示为 做到这里又遇到新的知识点了，模板注入漏洞 参考大佬的博客：一篇文章带你理解漏洞之 SSTI 漏洞，讲的非常详细 漏洞原理： SSTI 怎么产生的 服务端接收了用户的恶意输入以后，未经任何处理就将其作为 Web 应用模板内容的一部分，模板引擎在进行目标编译渲染的过

ssti模板注入从0到1 [BJDCTF2020]Cookie is so stable buu

WEB [CISCN 2019 初赛]Love Math 这题主要是通过给的那些函数来进行一个RCE，其中值得注意的就是进制转换函数base_convert()、dechex()了，我们的主要目的是造出来一个_GET，然后再通过这个来传入参数，进行RCE。而通过base_convert()函数可以进行任意进制间的一个转换，也就是可以构造出来任意的字符串，这里可以先通过一个base_convert()函数造出来一个hex2bin，然后通过dechex()函数把十进制转换成16进制，然后通过hex2bin()这

buuctf-[BJDCTF2020]Cookie is so stable(小宇特详解) 先看一下题目 有首页，有flag页面，有Hint页面 这里题目有提示，突破口是在cookie上面 这里先进行抓包分析 这里的知识点是利用服务端模板注入攻击。SSTI里面的Twig攻击 这里有判断模板注入类型的办法 输入{{7*‘7’}}，返回49表示是 Twig 模块 输入{{7*‘7’}}，返回7777777表示是 Jinja2 模块 这里在cookie处进行判断 user={{7*‘7’}},查看返回值

BUUCTF-web类-[BJDCTF2020]Cookie is so stable 题目提示Cookie，进入靶机就看看cookie， 目前看来没有什么异常，先看看页面，发现有flag按钮，查看一下 要我们输入一个id，随便输入个123看看， 回显我们的id，于是看了看我的cookie，发现Cookie中多了user参数。 初步猜想，有没有可能是Cookie注入？于是我输入了几个注入关键字测试...

PHP的模板注入 如果是在cookie处执行，最好抓包打payload，可能有url编码的问题 smarty模板注入 控制XFF进行命令执行（这是要在前端有IP相关回显的情况） payload: X-Forwarded-For: {{system("ls")}} 利用 {$smarty.version} //smarty的版本号 标签 {php} 可以使用{php}{/php}标签来执行被包裹其中的php指令 {php}phpinfo();{/php} Smarty已经废弃{php}标签，

这道题先点了一下没发现什么get参数，dirsearch和githack都扫了一下没啥收获，后面在hint源码中发现一行注释让我们仔细看cookie又回去在flag页面随便输个名字（只有这里有操作的地方），看到发了两个数据包，post方式包里面带两个请求体参数，不过cookie没有什么异常get型数据包里面发现多了一个参数usercookie一般存在什么问题，伪造身份，注入？这里伪造身份肯定不存在，那就只能注入了，但是有个问题是我们输入的数据被当做数据打印出来了，那就没法sql注入。

本文介绍了一个CTF解题过程：通过查看网页源代码发现提示后尝试抓包检查cookies，但未发现异常。在尝试SQL注入等方法无效后，参考他人解法发现需要使用SSTI（服务器端模板注入）漏洞。最终在抓包时发现user信息存储在cookie中，将模板注入代码写入cookie后成功获取flag。文章简要记录了从发现问题到最终解题的关键步骤，重点在于识别出SSTI注入点并利用cookie传递攻击载荷。

运用的知识点 SSTI注入 题目 解题 一开始看到题目提示cookie 先抓一个包试试 没发现什么问题，点开另一个网页 感觉是注入的题目，但是sql注入没啥反应。但是你输入什么他就会回显什么 联想到SSTI注入，构造PL进行尝试： 发现确实能够利用SSTI 判断是twig,构造PL：{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}} 发现不是在这里绕过，我们抓取一个登录的包

hint.php提示在cookie里有线索 更改flag.php里cookie的user参数就会有回显，之后就测试了sql，xss等都没有用 看了wp得知是模板注入 ==== 这里买123都会失败 买4会提示只能有一个字符 这里应该就是买到4就会得到flag，所以我们要找到有一个字符表示几千的数字 因为这里为utf-8，是unicode编码，所以查找unicode表示几千的字符 ...