TBTL CTF [web] Mexico City Tour

Mexico City Tour
100

Our colleague is currently on vacation in Mexico City and is using a local website to calculate distances between subway stations. We have information that the database contains a city FLAG. Can you uncover the secret? Perhaps we can identify a vulnerability and secure a free vacation for our colleague.

可以看出这是一道 SQLi。以下是源码：
用到了 neo4j.GraphDatabase 数据库，语法跟 sql 不太一样。通过阅读文档或 gpt-4 可以构造 payload 获取城市的信息。
100}) RETURN n.id AS distance;//
这句话相当于是指定返回 id=100 的那个城市。题目中说，有一个城市叫做 FLAG，我们可以把那个 FLAG 的 id 通过 WHERE 条件返回：
200}) WHERE n.name = "FLAG" RETURN n.id AS distance;//
发现 FLAG 的 id 是 -1。

现在我们知道这个 FLAG 的 name 是 “FLAG”，id 是 -1，但是我们不知道答案存在它的那个属性中。通过 gpt-4 我们可以使用 keys(n) 来获取一个 List[String]，但是如果我们直接返回它的话，服务器会 500 错误。阅读 python 代码发现它强制转成 int 了，这里会出错。所以我们不能直接读。改成 "flag" in keys(n) 就可以了。这里多试一下就可以试出这个 flag 的属性的名字，如果试不出来也可以用后面的方法读 keys(n)。

接下来可以用 STARTS WITH 来逐位获取 n.flag。本来如果能把 string 打包成 ascii 之类的，可以不用逐位分析。但是阅读文档并没有发现这样的函数，除了能用 substring 和 toInt 来直接返回是数字的位。真要加速（可能）可以用二分。

我们可以先 RETURN size(n.flag) 来看一看长度，长度是 30。直接逐位的话，不带多线程会比较卡。所以我们使用多线程。这里对每一位用多线程，即：

对 [5, 29) 开线程，配合 queue.SimpleQueue 做多线程通信，快了很多。大概是 TCP 阻塞机制的问题。

可能不是很难，毕竟 CTF 都是有线索的