【Web安全技术】CTF期中考核

发表于 2025-11-04 更新于 2025-11-20 分类于 Web 本文字数： 851

web，真神奇啊…你说flag是怎么出来的呢

1

开发者工具看响应里就有flag字段

ZmxhZ3tjb29raWVzLWNvbnRhaW4taW5mb30%3D

也就是

1	ZmxhZ3tjb29raWVzLWNvbnRhaW4taW5mb30=

base64解码：

1	flag{cookies-contain-info}

2

登录页面有提示，不是root登了没用。但是输入root登录又会提示禁止root

查看源代码，有个判断root的函数

直接禁掉就好了。运行window.check = function() { return true; };，再用root登录

又提示host非法，还得改host

使用burpsuite打开抓包，修改用户为root，host为localhost

登进去就得到flag

后来学习了，用curl也行而且很方便

1	curl -i -X POST http://39.102.144.60:30002/index.php -H "Host: 127.0.0.1" -d "name=root"

3

三个url，先全看一遍

csrf这个页面有提示，flag最后应该是在这拿

搜一下这是啥意思

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种攻击方式，攻击者诱导用户在已登录的网站上执行非本意的操作。

Django使用CSRF令牌来防止跨站请求伪造。当用户访问一个包含表单的页面时，Django会设置一个CSRF令牌在cookie中（通常名为csrftoken）和在表单中的一个隐藏字段（名为csrfmiddlewaretoken）。当用户提交表单时，Django会检查这两个令牌是否匹配。

所以大概是要找CSRF token。admin页面就有

源代码里还可以找到一个

1	csrfmiddlewaretoken=4nYZl1JSAUlOiEzhJnxEWPlbNvTDlVXb

看了下这段好像是登录时的POST逻辑，用户输入用户名密码的值，而csrf这个值是固定且隐藏的（那这个岂不是没用）。而且这两个不匹配啊

get了下csrf页面其实也有

（还有温馨提示）

这一段检查csrfmiddlewaretoken是否等于bypass，等于返回flag

1 2	<!-- if request.POST['csrfmiddlewaretoken'] == 'bypass': --> <!-- return render(request, 'index.html', {'message': 'flag{******}'}) -->

所以试一下设成bypass

1	curl -i -X POST "http://39.102.144.60:30003/csrf/" -H "Cookie: csrftoken=bypass" -d "csrfmiddlewaretoken=bypass"

真的有啊

看看difficult思路。根据源代码提示以及GA页面提示问ai

CVE-2016-7401
Google Analytics 会把来源信息（utm / __utmz）写入 __utmz cookie，且 utmcct（referer path）由浏览器的 Referer 决定。攻击者可以通过构造带有恶意 path 的页面，使 __utmz 包含攻击者控制的字符串。

某些服务器端/语言（典型的是 Python 的 http.cookies.SimpleCookie()/Django 在历史上有解析宽松的行为）把 cookie 字符串解析成键值对时，会把 ]、,、空格等字符当作非标准分隔符，从而把 __utmz 中嵌入的 ]csrftoken=... 解析出来当成真正的 csrftoken cookie（即注入或覆盖原有 CSRF cookie）。

如果站点的 CSRF 保护是 cookie+请求参数/表单令牌比较（典型 Django 模式：cookie 中的 csrftoken 与表单里的 csrfmiddlewaretoken 一致），我们就可以通过注入 cookie，把服务器端认为的 CSRF cookie 值改成我们控制的值，再提交一个携带同值表单，完成 CSRF 绕过并触发敏感操作（例如 admin 操作、follow、change password 等）。