Misc

Web部分 True_check_in 题目链接：http://144.202.82.121:23333/ 看到题肯定就先按要求来咯。先算了一下 2 的 33 次方等于多少： 填入结果发现问题：输入框限制了字符串长度，导致了不能够将结果 8589934592 直接输入提交。 尝试传入错误结果，返回 wrong。 于是尝试使用 BurpSuite 进行抓包，截获请求头： 发现用户输入的结果是通过 answer 的值使用 POST 方法传至服务器的，遂通过 BurpSuite 直接修改 answer 的值为 8589934592，然后提交请求，得到 flag： check_in 题目链接：http://47.107.115.177:2333/ 打开页面，发现只有这么一句话，查看源代码没发现什么猫腻，因为源代码也只有这一句话… 再打开审查元素界面看看请求头和响应头，发现了一个陌生的面孔 ETag ： 以下是 Wikipedia 对ETag的解释： ETag 是 HTTP 协议提供的若干机制中的一种 Web 缓存验证机制，并且允许客户端进行缓存协商。这就使得缓存变得更加高效，而且节省带宽。如果资源的内容没有发生改变，Web 服务器就不需要发送一个完整的响应。 ETag 是一个不透明的标识符，由 Web 服务器根据 URL 上的资源的特定版本而指定。如果那个 URL 上的资源内容改变，一个新的不一样的 ETag 就会被分配。用这种方法使用 ETag 即类似于指纹，并且他们能够被快速地被比较，以确定两个版本的资源是否相同。 如果 ETag 值匹配，这就意味着资源没有改变，服务器便会发送回一个极短的响应，包含 HTTP “304 未修改” 的状态。 304 状态告诉客户端，它的缓存版本是最新的，并应该使用它。 定睛一看，上面的 HTTP 状态码就是 304。那么更多的页面信息会不会在缓存里面呢？ 打开浏览器缓存目录，找到了该页面的 5 个缓存文件：...