BSidesSF 2020 CTF writeup

原创 唐龙 合天智汇

前言

前两天玩了下BsidesSF 2020，本文记录了所有WEB题的解答。

Writeup

csp-1

前3道都是考察CSP绕过，直接来看CSP规则：

src属性可以用data:，可以用来执行JS：

connect-src为*，可以用ajax外传数据。

获取flag的payload:

第一题比较简单。

csp-2

CSP规则：

script-src允许了ajax.googleapis.com，表示js可以从这里加载；unsafe-eval表示允许使用eval()等通过字符串创建代码的方法。 这个场景是典型的利用CDN上的旧JS框架来绕过CSP，也叫代码重用攻击。 可参考：

• A Wormable XSS on HackMD!
  
• Breaking XSS mitigations via Script Gadgets
  

利用最终的payload：

csp-3

CSP规则：

从 robots.txt 可得知/redirect?url=http://example.com存在301跳转漏洞。

storage.googleapis.com是firebase存储文件的域名。我们可以先在firebase创建项目并上传文件，然后在https://console.cloud.google.com/storage/browser/{bucket}给文件添加一个叫”allUsers“的权限。就能获得一个任何人可访问的js：http://storage.googleapis.com/{bucket}/xss.js。

但是这个url的路径部分和CSP是不匹配的，得想办法绕过。

根据CSP Level 3, 7.6. Paths and Redirects，跳转之后路径部分会被忽略。例如对于策略img-src example.com example.org/path： 直接加载https://example.org/not-path将失败，因为它与策略不匹配。 加载https://example.com/redirector，由于它和example.com匹配，故能通过。 * 假设https://example.com/redirector重定向到https://example.org/not-path，也将通过。因为跳转前匹配上了example.com，跳转后匹配上了example.org（路径部分被忽略）。

利用这个特点，让/redirect跳转到http://storage.googleapis.com/{bucket}/xss.js，则策略中的/good.js将被忽略，从而绕过该CSP。

这里还有个细节，题目使用的是https，而CSP里写的是http://storage.googleapis.com/good.js是http，即使绕过了CSP，浏览器也不会允许从https降级请求http资源。

根据CSP3的文档，CSP规则的协议部分的匹配是不对称的，例如： https: 不能匹配 http://example.com/ http: 可以匹配 http: 和 https:

所以，我们可以跳转到https上，也是可以过CSP的。

最终的payload：

xss.js：

fun-with-flags

这道题只能插入style>标签，插入其他标签会被实体化编码，显然是考察CSS注入。要获取的flag在：

利用CSS选择器和background猜解flag，POC：

逐位猜解即可，脚本：

simple-todos

此题使用了一套叫meteor的框架来构建了一个web应用。 由于开了debug，我们可以通过dev tools来检查源码。

有意思的是，这个应用居然在客户端操作mongodb。 通过抓包发现，这并不是在客户端直接连接远端mongodb，而是通过websocket与server端通信，真正的数据库操作还是在server端实现的。不过，既然存在这种映射，也相当于我们可以直接操作数据库了。

flag在一个叫flag的**里：

recipe

题目描述：

注册账号登录后，在网页源码内可以发现一个新的端点：/users。直接访问提示”Access only allowed from local tools.Recipebot server at 0.0.0.0:8080“。

在/recipe/new端点可以提交一个url，这是一个下载远程图片的功能。这里存在SSRF，过滤了内网IP，但是0.0.0.0没有过滤。

通过SSRF请求http://0.0.0.0:8080/users，得到所有注册用户的用户名和一串id。

根据题目描述，flag应该在boudin_bakery这个账号里。直接访问/profile/6180f0c8-778b-442f-a5ab-10e18bef4c2d提示404。

注意到cookie是jwt的形式：

将header和payload部分base64解码（前两部分）

解码payload部分时如果末尾没有}需要手动补齐=再解码。

各字段的意义： alg：token所用的签名算法 typ：token类型，JWT表示JSON Web Token exp：token过期时间 iat：token创建时间 iss：token的颁发者 nbf：token的生效时间 * sub：面向的用户

sub字段就是用户身份标识，也就是/users端点泄露出来的那些。 显然，我们要伪造cookie。jwt的第三部分是签名，签名是需要秘钥的。 这里加密算法用的HS256，签名和校验的秘钥相同。 所以要伪造cookie有2种方式： 爆破出签名的secret：c-jwt-cracker26900112 修改算法为none，去掉签名（保留末尾的点号）

法2的原理： 一些jwt库中实现了none算法，这种情况下将不校验签名。

尝试将sub换成boudin_bakery的，修改alg为none，并去掉签名字段（要保留末尾的点号）。伪造cookie访问/recipes即可得到flag。

had-a-bad-day

题目描述：

端点：/index.php?category=woofers

容易测试出后端代码逻辑：

利用文件包含读取文件的常用payload：

这里考察的是如何绕过strpos($cate, "woofers")。

我发现了两种绕过方式： php://filter/read=convert.base64-encode/resource=meowers/../flag php://filter/read=convert.base64-encode|meowers/resource=flag

第一种利用了PHP会对路径进行规范化处理；第二种利用了PHP对不存在过滤器的容错性，虽然会报warning，但是还是输出了结果。

hurdles

这题比较无聊，套娃题。 payload：

转载请注明来自网盾网络安全培训，本文标题：《BSidesSF 2020 CTF writeup》

标签：CTF网络安全