# Puzzle
纯粹的逻辑题，但是很有迷惑性（一开始我甚至没注意到）
直接看源代码很容易就能发现几乎没有地方可以 SQL 注入，直接 PASS,localhost 的判定没法绕过，况且 uuid 也不是能控制的东西。
但是通过看 routes 就能发现系统内置了一个 admin 账户，并且禁止注册 admin：
但是有很多路由都有验证 admin，不难看出我们首先就是要拿下这个账号，然后可以发现下面几个有趣的地方：
1. 注册时身份
默认是 user，但是可以注册时改包让自己成为 editor
2. 查询用户信息的接口
这里有判断访问者身份，但是却不只是 admin，即使是 editor 也能访问，返回账号密码，这意味者当我们使用上面得到的 editor 账户，只要能够得到 admin 的 uuid, 就可以得到其密码并登录
怎么得到呢。看其他功能，哪里有返回非自己的 uuid：
看这里的 SQL 查询，将共同作者的 uuid 也返回了，这样我们只需发表一篇共同作者是 admin 的文章就行
但是实际发表后，会发现没法查询到这篇文章。问题在于此时文章状态时 pending，还不在这个表里，好在：
这个接受的邀请虽然禁止了 admin 本身访问接受合作邀请，但是却没有验证接受这个邀请的是不是被邀请的这个人本人。我们可以直接以普通用户的身份使得 admin 接受邀请。
这时就可以利用上面的 article 路由查询出 admin 的 uuid，进而使用这 editer 用户访问 users 路由得到 admin 的信息
接下来直接登上去，访问之间看到的存在 ssti 的地方，然后死磕：
死磕在这里...... 那就没救了，不妨看看还有什么只有 admin 的用的，比如下面这个：
这里面有俩文件，下载下来：
压缩文件有密码，里面是个 txt，显然我们要得到这个密码，那么 exe 呢？一般容器都不会使用 windows，怎么会来个 exe, 明显有鬼，丢进 IDA 看看：
用于连接数据库
明明是要输入的，却自带了内容，而且创建后就立马删除，明显有问题，会不会这里面的 password 其实是解压密码：
是的，真的是的
解压即得 flag：
PS:
一开始我都没发现这里有个 SSTI，是通过 Wells 神力得知的，也是因为 Wells 神力知道了并非 SSTI，要不然我估计会死磕到最后也没做出来......
# Secrets
看不懂.jpg
目前已知的情报：
1. 虽然 dockerfile 和 compose 文件都没有配置 secret 环境变量，但是也并非'supersecret'
可以确定是个幌子，admin 密码当然也是假的。flag 在单独的表中，但是没有找到哪里有对应的查询语句
2. 不是 SQL 注入（？)
3. 一样有个唯一的管理员用户，以及其能使用的特定路由。
4.report 可以用 GET 方法以管理员的身份访问给出的本地 URL, 但是没有回显。
目前的思路是得到 CSRFtoken，伪造 admin 的提交。
