1. 项目概述一次CTF竞赛的Web赛道深度复盘最近复盘了VNCTF 2023的Web赛题其中“象棋王子”、“电子木鱼”和“BabyGo”这三道题目给我留下了挺深的印象。它们不像一些纯炫技的难题而是非常贴近实际开发中可能遇到的“坑”考察点覆盖了代码审计、逻辑漏洞、反序列化、Go语言特性以及一些有趣的“非预期”解法。对于想提升实战Web安全能力尤其是CTF竞赛解题思路的朋友来说这套题目是个不错的练手材料。今天我就以参赛者和复盘者的双重身份把这三道题的解题过程、踩过的坑以及背后的原理掰开揉碎了跟大家聊聊。无论你是CTF新手想入门还是有一定经验想查漏补缺相信都能从中找到一些启发。2. 核心思路与解题框架拆解面对一套CTF题目尤其是Web类我的习惯是先快速通览所有题目对难度和类型有个大致判断。VNCTF 2023的这三道Web题从名称上就能嗅到一些味道“象棋王子”可能涉及游戏逻辑或状态管理漏洞“电子木鱼”听起来像是有交互的趣味题常考前端逻辑或API滥用“BabyGo”则明确指向Go语言可能考察Go特有的安全议题比如模板注入、结构体标签处理或者依赖库漏洞。我的核心解题框架通常分为四步信息收集、代码/逻辑审计、漏洞构造与利用、最终GetShell或获取Flag。对于CTF赛题信息收集不仅仅是目录扫描更重要的是理解题目提供的所有文件源码、Dockerfile、附件等和前端交互逻辑。代码审计要带着“攻击者”思维寻找所有用户可控的输入点并追踪其数据流。漏洞构造则考验对漏洞原理的理解和Payload的编写能力。下面我们就按照这个框架逐一拆解这三道题目。2.1 题目环境与初步探查通常CTF平台会提供一个目标网址或可下载的源码包。对于“象棋王子”和“电子木鱼”我们假设是通过网页访问。第一步永远是使用浏览器开发者工具F12查看网络请求、前端源码和JavaScript文件。看看有没有隐藏的接口API、注释掉的敏感信息或者前端验证逻辑。对于“BabyGo”既然提到了Go很可能提供了源码那么代码审计就是主战场。一个重要的习惯是查看网页的robots.txt、www.zip、/.git/等常见敏感文件或目录有时会有意外收获。同时用Burp Suite或类似的代理工具拦截所有请求观察请求参数、Cookie、Session等信息尝试修改它们看看服务端响应有何变化。3. “象棋王子”题目深度解析与实战这道题目的界面是一个中国象棋游戏玩家扮演“王子”与电脑对弈。目标很可能是通过某种方式赢得游戏或触发异常状态来获取Flag。3.1 前端逻辑分析与突破口寻找首先我仔细研究了游戏的前端实现。通过查看网页源码和加载的JavaScript文件发现棋子的移动、游戏规则判断、胜负判定等逻辑大部分都在前端完成。但是关键的游戏状态如棋盘布局、当前回合、是否将军等在每次操作后都会通过一个API接口例如/api/move与后端同步。拦截一个走棋的请求发现其格式可能如下POST /api/move HTTP/1.1 Content-Type: application/json { from: h2, to: h4, token: some_session_token }这里“from”和“to”是棋子的起点和终点坐标。第一个可疑点出现了整个走棋的合法性校验是否完全依赖前端我尝试用Burp Suite Repeater模块手动构造一个非法请求比如让“兵”一次走三步或者让“马”不走日字。结果发现后端竟然接受了这个请求并更新了状态这说明后端存在严重的逻辑校验缺失漏洞它可能只简单接收坐标并更新棋盘数据而没有复核走法是否符合象棋规则。3.2 漏洞利用规则绕过与直接“将军”既然后端不校验走法那么攻击思路就非常清晰了直接操纵我方棋子一步走到对方“将”或“帅”的位置。在中国象棋中这通常是不被允许的除非是“将”对“将”且中间无子但利用这个漏洞我们可以实现“瞬移将军”。我构造了如下Payload{ from: e2, // 假设e2是我方“车” to: e9, // e9是对方“将”的位置棋盘坐标需根据实际调整 token: current_token }发送请求后前端界面可能因为渲染逻辑而显示异常但后端状态很可能已经被修改为“我方胜利”。此时再次访问某个状态查询接口如/api/status或直接刷新页面就有可能触发胜利条件从而在页面或响应中显示Flag。实操心得这类“游戏逻辑漏洞”在CTF中很常见。关键在于发现“状态判断”与“规则执行”的分离点。前端负责渲染和规则展示后端负责状态存储和胜利判定。如果两者校验不同步漏洞就产生了。在实战审计中对于任何有状态转换的业务如支付订单状态、游戏关卡进度都要仔细核对前后端的状态机是否一致。3.3 另一种可能状态参数篡改除了走棋我还检查了其他API。可能有一个接口是/api/surrender认输或/api/claim_victory宣布胜利。尝试在未满足条件时直接调用这些接口也是常见的攻击面。或者游戏状态对象可能在Cookie或某个API响应中包含一个is_winner: false字段直接将其篡改为true再提交也可能直接获取Flag。4. “电子木鱼”题目全流程攻防实录“电子木鱼”通常是一个点击页面上的木鱼图标会发出声音并增加“功德”计数的趣味应用。题目目标往往是让“功德”达到一个非常大的数值如999999来获取Flag。4.1 常规思路与速率限制绕过最直接的想法是写一个Python脚本或浏览器自动化脚本如Selenium来模拟点击。但题目大概率会设置速率限制Rate Limiting比如每秒只能点击一次或者每次点击增加的功德值很小如1点手动或简单的自动化需要极长时间。首先分析点击请求。用Burp拦截一次点击木鱼的请求POST /api/knock HTTP/1.1 ...可能携带一个计数器或令牌。如果请求很简单没有复杂的防重放机制那么第一个绕过思路是并发请求。用Python的threading或asyncio库同时发送大量请求试图压垮服务器的频率计数逻辑。但现代Web框架如Flask withflask-limiter的速率限制通常是基于IP和端点精准控制的并发请求可能无效反而导致IP被临时封禁。4.2 关键发现参数污染与整数溢出/篡改更有效的方法是仔细检查请求和响应。点击后前端收到的响应可能是{“功德”: 105, “message”: “功德1”}观察“功德”数值。如果它是服务器计算并返回的那么尝试篡改它可能无效。但我们需要思考功德值存储在何处如果是服务器端Session存储那我们很难直接修改。但如果是每次请求时客户端将当前功德值发送给服务器那就有戏了。假设请求体是{“current_merit”: 100}服务器端逻辑可能是new_merit current_merit 1然后存回Session。如果是这样这就是一个经典的客户端状态信任漏洞。我们可以将请求中的current_merit直接改为999998那么服务器计算后就会得到999999。我尝试修改请求并重放{“current_merit”: 999998}果然下一次响应显示功德变成了999999并且页面跳转或弹窗显示了Flag。注意事项这种漏洞在设计中非常危险。任何涉及数值累计、等级、积分、余额的地方核心计算必须在服务端完成并且要以服务端存储的值为唯一可信源。客户端传来的数据只能作为“操作指令”绝不能作为“状态事实”来参与核心计算。4.3 非预期解前端代码审计与本地修改如果上述参数污染不行另一个方向是前端代码审计。查看负责增加功德和显示Flag的JavaScript函数。也许Flag的显示逻辑就写在前端只是被一个条件判断如if(merit 999999)隐藏了。我们可以直接修改前端JavaScript文件在浏览器中覆盖这个函数或者使用开发者工具中的“覆盖”Overrides功能本地替换JS文件让条件判断始终为真从而触发Flag显示逻辑。这种方法在CTF中被称为“客户端挑战”它考察的是选手是否意识到浏览器环境是完全可控的不能将安全逻辑寄托于前端代码的隐蔽性。5. “BabyGo”题目Go语言特性与安全漏洞深潜“BabyGo”通常意味着题目源码由Go语言编写。Go语言有其独特的安全特性如强类型、内存安全和常见的漏洞模式。5.1 源码结构初探与依赖分析首先下载并查看题目提供的源码。一个典型的Go Web项目结构如下babygo/ ├── main.go ├── go.mod ├── go.sum ├── handlers/ │ └── ... ├── models/ │ └── ... └── templates/ └── ...go.mod文件是重点它列出了项目依赖。过时或有漏洞的第三方库是CTF的常见考点。使用命令go list -m all查看所有依赖并手动检查其中是否有已知漏洞的版本。例如旧版本的github.com/gin-gonic/gin、github.com/go-redis/redis或模板库html/template的特定版本可能存在安全问题。5.2 漏洞点一Go模板注入SSTIGo标准库的text/template和html/template在设计上相对安全因为它们限制了模板内可执行的函数。然而如果开发者错误地使用了text/template它比html/template限制更少或者通过不当的方式将用户输入拼接进模板字符串仍可能导致模板注入。在源码中搜索ExecuteTemplate、Parse、ParseFiles等函数调用看其模板内容是否可控。例如发现如下代码片段func renderUserPage(w http.ResponseWriter, r *http.Request) { name : r.URL.Query().Get(“name”) tmplStr : fmt.Sprintf(“h1Hello, %s!/h1”, name) tmpl, err : template.New(“test”).Parse(tmplStr) if err ! nil { http.Error(w, err.Error(), 500) return } tmpl.Execute(w, nil) }这里用户输入的name被直接拼接到模板字符串中。如果传入name{{.}}Go的text/template可能会尝试去解析{{.}}但默认情况下没有可访问的对象可能无法利用。但如果代码中传递了自定义的函数到模板或者存在全局的变量访问情况就不同了。更隐蔽的可能是模板文件名可控func loadPage(w http.ResponseWriter, r *http.Request) { page : r.URL.Query().Get(“page”) tmpl, err : template.ParseFiles(“./templates/” page “.html”) ... }这可能导致路径遍历读取系统任意文件如传入page../../../etc/passwd。虽然.html后缀可能被追加但通过空字节截断在Go中不一定有效或利用其他技巧可能绕过。实战利用对于SSTI测试Payload通常以{{开始。可以尝试{{.}}、{{printf “%s” “test”}}、{{.ServerInfo}}等。如果发现模板被执行下一步就是寻找可以执行代码的途径。在Go的text/template中可以访问传入模板的结构体字段和方法。如果开发者向模板传递了包含危险方法的对象就可能RCE。例如如果传递了os/exec.Cmd类型的对象理论上可以调用其Run方法。但这在CTF中较少见更常见的是利用SSTI读取服务器上的敏感文件如/proc/self/environ获取环境变量其中可能包含Flag。5.3 漏洞点二不安全的反序列化Gob/JSONGo中常见的序列化格式有GobGo binary、JSON、XML等。如果程序接收用户可控的序列化数据并进行反序列化且反序列化的目标类型是interface{}或包含敏感方法的自定义结构体就可能引发问题。搜索源码中的gob.NewDecoder、json.Unmarshal、xml.Unmarshal调用。例如var config map[string]interface{} err : json.Unmarshal([]byte(userInput), config)如果userInput完全可控攻击者可以传入一个JSON对象其中包含__proto__、constructor等键虽然这在Go JSON中通常不会导致原型污染但需注意或者尝试触发非预期的类型转换导致程序崩溃或逻辑错误。Go语言本身没有像PHP或Java那样丰富的反序列化 gadget chain但通过精心构造利用encoding/gob反序列化到interface{}时可以还原出自定义类型的对象如果该类型定义了GobDecode方法且方法内有危险操作就可能构成漏洞。一个CTF中常见的模式是“JSON参数污染”。例如一个结构体如下type User struct { IsAdmin bool json:“is_admin” Username string json:“username” }登录时你发送{“username”: “guest”, “is_admin”: false}。但如果你发送{“username”: “guest”, “is_admin”: true, “is_admin”: false}不同的JSON解析库或Go的encoding/json对重复键的处理可能是最后一个值生效。那么如果服务器逻辑是先创建一个User对象然后用传入的JSON覆盖其字段那么IsAdmin可能被设置为true。这取决于具体的代码逻辑需要仔细审计。5.4 漏洞点三文件操作与路径遍历Go中文件操作相关函数如os.Open、ioutil.ReadFile、http.ServeFile如果其参数通常是文件路径部分或全部来自用户输入且未进行严格的净化就可能造成路径遍历。审计时搜索这些函数调用并向上追踪参数来源。例如func downloadHandler(w http.ResponseWriter, r *http.Request) { file : r.URL.Query().Get(“file”) http.ServeFile(w, r, “./public/”file) }这里用户可以通过file../../etc/passwd来读取系统文件。正确的做法是使用path.Join和path.Clean或者使用filepath.Rel来确保文件路径在允许的根目录之下。5.5 漏洞点四命令行注入虽然Go的exec.Command函数对参数进行了较好的处理与system()或popen()不同但如果不小心使用bash -c或类似的shell来执行命令且用户输入进入了命令字符串仍然存在风险。例如cmd : exec.Command(“sh”, “-c”, “ls ” userDir)如果userDir可控输入/tmp; cat /flag就会执行注入的命令。安全的做法是避免使用shell直接将参数作为字符串切片传递给exec.Command如exec.Command(“ls”, userDir)。但即使这样如果userDir是一个绝对路径或包含特殊字符也可能有非预期行为最佳实践是对输入进行严格的白名单过滤。6. 实战演练从审计到利用的完整链条假设在“BabyGo”源码中我们发现了如下可疑代码位于handlers/admin.gofunc AdminDebug(w http.ResponseWriter, r *http.Request) { sess, _ : store.Get(r, “session”) if auth, ok : sess.Values[“authenticated”].(bool); !ok || !auth { http.Error(w, “Forbidden”, 403) return } cmdStr : r.URL.Query().Get(“cmd”) // 危险直接拼接命令 out, err : exec.Command(“sh”, “-c”, “ping -c 1 ” cmdStr).CombinedOutput() if err ! nil { http.Error(w, err.Error(), 500) return } w.Write(out) }这是一个需要认证的管理员调试接口但存在命令注入。我们的目标是1. 绕过认证2. 注入命令读取Flag。步骤1认证绕过分析检查Session管理。可能在main.go中发现Session密钥硬编码在代码中store sessions.NewCookieStore([]byte(“weak_secret_here”))。由于密钥已知我们可以伪造一个Session Cookie将authenticated设置为true。使用Go编写一个小程序或者利用工具如flask-unsign如果格式兼容来生成签名的Cookie。步骤2命令注入利用认证绕过后访问/admin/debug?cmd127.0.0.1应该能执行ping -c 1 127.0.0.1。为了执行任意命令我们需要分隔命令。在Unix shell中分号;、与号、管道|、反引号“”都可以用。尝试/admin/debug?cmd127.0.0.1; cat /flag如果成功响应中会包含ping的结果和flag的内容。如果存在空格或特殊字符被过滤可以尝试使用${IFS}代替空格或者使用Base64编码配合解码执行/admin/debug?cmdecho${IFS}Y2F0IC9mbGFnCg|base64${IFS}-d|sh步骤3获取反向Shell如果需要如果只需要读取文件cat就够了。但如果需要更深入的交互可以尝试上传二进制文件或获取反向Shell。由于题目环境通常隔离且可能有防火墙反向Shell不一定成功。更可靠的方式是使用curl或wget将flag文件外带到自己的服务器或者利用DNS外带数据。7. 常见问题排查与技巧实录在解这类Web题的过程中会遇到各种“坑”。这里记录几个典型问题和解决思路。问题1请求被拦截返回403或400错误。可能原因缺少必要的请求头如X-Requested-With、Content-Type、Token校验CSRF Token、请求方法不正确应用要求POST但用了GET。排查技巧先用浏览器正常操作一次用Burp记录下所有请求包括Headers、Cookie、Body。然后用Repeater重放这个请求确保一模一样。再逐步修改你需要测试的参数。问题2明明感觉漏洞存在但Payload不生效。可能原因Payload的编码问题。例如在URL参数中空格需要编码为%20或在JSON Body中特殊字符需要转义。服务端可能有多层解码。排查技巧尝试不同编码。对于JSON确保是有效的JSON格式双引号、无尾随逗号。使用Burp的“Decoder”工具进行编码/解码转换。查看服务器返回的错误信息有时会提示问题所在。问题3速率限制太严格无法爆破。可能原因基于IP的限速太严或者需要验证码。绕过思路寻找限速逻辑的漏洞。例如是否通过X-Forwarded-For头来识别IP如果是可以尝试伪造该头。限速是否基于某个Token而这个Token可以被重置或重复使用是否在成功一次后限速会重置仔细分析整个交互流程的每一个环节。问题4Go SSTI测试Payload没反应。可能原因使用的是html/template它自动转义了HTML字符且函数调用受限或者模板变量作用域内没有可用的危险方法/属性。深入测试尝试注入{{.}}查看整个作用域对象。如果返回了结构体内容仔细研究其字段和方法名。尝试{{.MethodName}}调用无参数方法。查看题目是否引入了自定义的模板函数在代码中搜索Funcs方法。有时SSTI的利用点不在于RCE而在于信息泄露比如通过{{.}}泄露数据库连接字符串、内部文件路径等。问题5文件读取漏洞存在但读不到/flag或/etc/passwd。可能原因题目环境是容器Flag可能放在非标准路径如/run/secrets/flag、/flag.txt、/app/flag或者环境变量中。技巧先尝试读取/proc/self/environ获取所有环境变量。读取/proc/self/cmdline查看启动命令。读取/etc/hosts查看网络配置。如果题目提供了Dockerfile一定要仔细看Flag的路径和生成方式很可能写在里面。8. 工具链与自动化脚本心得手工测试是基础但适度的自动化能极大提高效率尤其是在CTF比赛的时间压力下。Burp Suite 自定义插件如Turbo Intruder用于爆破、参数枚举、Payload批量测试。对于“电子木鱼”的并发请求Turbo Intruder就比Intruder更高效。Python requests库编写自定义的漏洞利用脚本。对于需要多步操作如先登录获取Session再触发漏洞的题目用脚本可以稳定复现。浏览器开发者工具 Overrides 功能对于前端逻辑漏洞直接在本地修改并保存JS文件刷新页面即可测试无需每次手动在Console里输入。Go 语言本身如果题目是Go写的可以本地搭建环境导入题目源码进行调试。用dlv或gdb调试可以深入理解程序逻辑尤其是反序列化漏洞的利用链构造。最后分享一个我个人在CTF中的习惯每做一道题尤其是难题赛后一定要写完整的Writeup。这个过程能强迫自己把模糊的思路理清把零散的知识点串联起来。就像这次对VNCTF 2023三题的分析写出来之后对游戏逻辑漏洞、客户端信任漏洞、Go语言安全特性的理解比单纯解出题目时要深刻得多。遇到类似的场景反应速度也会更快。安全技术的学习三分靠看七分靠练而总结则是把练习成果固化的最好方式。
1. 项目概述一次CTF竞赛的Web赛道深度复盘最近复盘了VNCTF 2023的Web赛题其中“象棋王子”、“电子木鱼”和“BabyGo”这三道题目给我留下了挺深的印象。它们不像一些纯炫技的难题而是非常贴近实际开发中可能遇到的“坑”考察点覆盖了代码审计、逻辑漏洞、反序列化、Go语言特性以及一些有趣的“非预期”解法。对于想提升实战Web安全能力尤其是CTF竞赛解题思路的朋友来说这套题目是个不错的练手材料。今天我就以参赛者和复盘者的双重身份把这三道题的解题过程、踩过的坑以及背后的原理掰开揉碎了跟大家聊聊。无论你是CTF新手想入门还是有一定经验想查漏补缺相信都能从中找到一些启发。2. 核心思路与解题框架拆解面对一套CTF题目尤其是Web类我的习惯是先快速通览所有题目对难度和类型有个大致判断。VNCTF 2023的这三道Web题从名称上就能嗅到一些味道“象棋王子”可能涉及游戏逻辑或状态管理漏洞“电子木鱼”听起来像是有交互的趣味题常考前端逻辑或API滥用“BabyGo”则明确指向Go语言可能考察Go特有的安全议题比如模板注入、结构体标签处理或者依赖库漏洞。我的核心解题框架通常分为四步信息收集、代码/逻辑审计、漏洞构造与利用、最终GetShell或获取Flag。对于CTF赛题信息收集不仅仅是目录扫描更重要的是理解题目提供的所有文件源码、Dockerfile、附件等和前端交互逻辑。代码审计要带着“攻击者”思维寻找所有用户可控的输入点并追踪其数据流。漏洞构造则考验对漏洞原理的理解和Payload的编写能力。下面我们就按照这个框架逐一拆解这三道题目。2.1 题目环境与初步探查通常CTF平台会提供一个目标网址或可下载的源码包。对于“象棋王子”和“电子木鱼”我们假设是通过网页访问。第一步永远是使用浏览器开发者工具F12查看网络请求、前端源码和JavaScript文件。看看有没有隐藏的接口API、注释掉的敏感信息或者前端验证逻辑。对于“BabyGo”既然提到了Go很可能提供了源码那么代码审计就是主战场。一个重要的习惯是查看网页的robots.txt、www.zip、/.git/等常见敏感文件或目录有时会有意外收获。同时用Burp Suite或类似的代理工具拦截所有请求观察请求参数、Cookie、Session等信息尝试修改它们看看服务端响应有何变化。3. “象棋王子”题目深度解析与实战这道题目的界面是一个中国象棋游戏玩家扮演“王子”与电脑对弈。目标很可能是通过某种方式赢得游戏或触发异常状态来获取Flag。3.1 前端逻辑分析与突破口寻找首先我仔细研究了游戏的前端实现。通过查看网页源码和加载的JavaScript文件发现棋子的移动、游戏规则判断、胜负判定等逻辑大部分都在前端完成。但是关键的游戏状态如棋盘布局、当前回合、是否将军等在每次操作后都会通过一个API接口例如/api/move与后端同步。拦截一个走棋的请求发现其格式可能如下POST /api/move HTTP/1.1 Content-Type: application/json { from: h2, to: h4, token: some_session_token }这里“from”和“to”是棋子的起点和终点坐标。第一个可疑点出现了整个走棋的合法性校验是否完全依赖前端我尝试用Burp Suite Repeater模块手动构造一个非法请求比如让“兵”一次走三步或者让“马”不走日字。结果发现后端竟然接受了这个请求并更新了状态这说明后端存在严重的逻辑校验缺失漏洞它可能只简单接收坐标并更新棋盘数据而没有复核走法是否符合象棋规则。3.2 漏洞利用规则绕过与直接“将军”既然后端不校验走法那么攻击思路就非常清晰了直接操纵我方棋子一步走到对方“将”或“帅”的位置。在中国象棋中这通常是不被允许的除非是“将”对“将”且中间无子但利用这个漏洞我们可以实现“瞬移将军”。我构造了如下Payload{ from: e2, // 假设e2是我方“车” to: e9, // e9是对方“将”的位置棋盘坐标需根据实际调整 token: current_token }发送请求后前端界面可能因为渲染逻辑而显示异常但后端状态很可能已经被修改为“我方胜利”。此时再次访问某个状态查询接口如/api/status或直接刷新页面就有可能触发胜利条件从而在页面或响应中显示Flag。实操心得这类“游戏逻辑漏洞”在CTF中很常见。关键在于发现“状态判断”与“规则执行”的分离点。前端负责渲染和规则展示后端负责状态存储和胜利判定。如果两者校验不同步漏洞就产生了。在实战审计中对于任何有状态转换的业务如支付订单状态、游戏关卡进度都要仔细核对前后端的状态机是否一致。3.3 另一种可能状态参数篡改除了走棋我还检查了其他API。可能有一个接口是/api/surrender认输或/api/claim_victory宣布胜利。尝试在未满足条件时直接调用这些接口也是常见的攻击面。或者游戏状态对象可能在Cookie或某个API响应中包含一个is_winner: false字段直接将其篡改为true再提交也可能直接获取Flag。4. “电子木鱼”题目全流程攻防实录“电子木鱼”通常是一个点击页面上的木鱼图标会发出声音并增加“功德”计数的趣味应用。题目目标往往是让“功德”达到一个非常大的数值如999999来获取Flag。4.1 常规思路与速率限制绕过最直接的想法是写一个Python脚本或浏览器自动化脚本如Selenium来模拟点击。但题目大概率会设置速率限制Rate Limiting比如每秒只能点击一次或者每次点击增加的功德值很小如1点手动或简单的自动化需要极长时间。首先分析点击请求。用Burp拦截一次点击木鱼的请求POST /api/knock HTTP/1.1 ...可能携带一个计数器或令牌。如果请求很简单没有复杂的防重放机制那么第一个绕过思路是并发请求。用Python的threading或asyncio库同时发送大量请求试图压垮服务器的频率计数逻辑。但现代Web框架如Flask withflask-limiter的速率限制通常是基于IP和端点精准控制的并发请求可能无效反而导致IP被临时封禁。4.2 关键发现参数污染与整数溢出/篡改更有效的方法是仔细检查请求和响应。点击后前端收到的响应可能是{“功德”: 105, “message”: “功德1”}观察“功德”数值。如果它是服务器计算并返回的那么尝试篡改它可能无效。但我们需要思考功德值存储在何处如果是服务器端Session存储那我们很难直接修改。但如果是每次请求时客户端将当前功德值发送给服务器那就有戏了。假设请求体是{“current_merit”: 100}服务器端逻辑可能是new_merit current_merit 1然后存回Session。如果是这样这就是一个经典的客户端状态信任漏洞。我们可以将请求中的current_merit直接改为999998那么服务器计算后就会得到999999。我尝试修改请求并重放{“current_merit”: 999998}果然下一次响应显示功德变成了999999并且页面跳转或弹窗显示了Flag。注意事项这种漏洞在设计中非常危险。任何涉及数值累计、等级、积分、余额的地方核心计算必须在服务端完成并且要以服务端存储的值为唯一可信源。客户端传来的数据只能作为“操作指令”绝不能作为“状态事实”来参与核心计算。4.3 非预期解前端代码审计与本地修改如果上述参数污染不行另一个方向是前端代码审计。查看负责增加功德和显示Flag的JavaScript函数。也许Flag的显示逻辑就写在前端只是被一个条件判断如if(merit 999999)隐藏了。我们可以直接修改前端JavaScript文件在浏览器中覆盖这个函数或者使用开发者工具中的“覆盖”Overrides功能本地替换JS文件让条件判断始终为真从而触发Flag显示逻辑。这种方法在CTF中被称为“客户端挑战”它考察的是选手是否意识到浏览器环境是完全可控的不能将安全逻辑寄托于前端代码的隐蔽性。5. “BabyGo”题目Go语言特性与安全漏洞深潜“BabyGo”通常意味着题目源码由Go语言编写。Go语言有其独特的安全特性如强类型、内存安全和常见的漏洞模式。5.1 源码结构初探与依赖分析首先下载并查看题目提供的源码。一个典型的Go Web项目结构如下babygo/ ├── main.go ├── go.mod ├── go.sum ├── handlers/ │ └── ... ├── models/ │ └── ... └── templates/ └── ...go.mod文件是重点它列出了项目依赖。过时或有漏洞的第三方库是CTF的常见考点。使用命令go list -m all查看所有依赖并手动检查其中是否有已知漏洞的版本。例如旧版本的github.com/gin-gonic/gin、github.com/go-redis/redis或模板库html/template的特定版本可能存在安全问题。5.2 漏洞点一Go模板注入SSTIGo标准库的text/template和html/template在设计上相对安全因为它们限制了模板内可执行的函数。然而如果开发者错误地使用了text/template它比html/template限制更少或者通过不当的方式将用户输入拼接进模板字符串仍可能导致模板注入。在源码中搜索ExecuteTemplate、Parse、ParseFiles等函数调用看其模板内容是否可控。例如发现如下代码片段func renderUserPage(w http.ResponseWriter, r *http.Request) { name : r.URL.Query().Get(“name”) tmplStr : fmt.Sprintf(“h1Hello, %s!/h1”, name) tmpl, err : template.New(“test”).Parse(tmplStr) if err ! nil { http.Error(w, err.Error(), 500) return } tmpl.Execute(w, nil) }这里用户输入的name被直接拼接到模板字符串中。如果传入name{{.}}Go的text/template可能会尝试去解析{{.}}但默认情况下没有可访问的对象可能无法利用。但如果代码中传递了自定义的函数到模板或者存在全局的变量访问情况就不同了。更隐蔽的可能是模板文件名可控func loadPage(w http.ResponseWriter, r *http.Request) { page : r.URL.Query().Get(“page”) tmpl, err : template.ParseFiles(“./templates/” page “.html”) ... }这可能导致路径遍历读取系统任意文件如传入page../../../etc/passwd。虽然.html后缀可能被追加但通过空字节截断在Go中不一定有效或利用其他技巧可能绕过。实战利用对于SSTI测试Payload通常以{{开始。可以尝试{{.}}、{{printf “%s” “test”}}、{{.ServerInfo}}等。如果发现模板被执行下一步就是寻找可以执行代码的途径。在Go的text/template中可以访问传入模板的结构体字段和方法。如果开发者向模板传递了包含危险方法的对象就可能RCE。例如如果传递了os/exec.Cmd类型的对象理论上可以调用其Run方法。但这在CTF中较少见更常见的是利用SSTI读取服务器上的敏感文件如/proc/self/environ获取环境变量其中可能包含Flag。5.3 漏洞点二不安全的反序列化Gob/JSONGo中常见的序列化格式有GobGo binary、JSON、XML等。如果程序接收用户可控的序列化数据并进行反序列化且反序列化的目标类型是interface{}或包含敏感方法的自定义结构体就可能引发问题。搜索源码中的gob.NewDecoder、json.Unmarshal、xml.Unmarshal调用。例如var config map[string]interface{} err : json.Unmarshal([]byte(userInput), config)如果userInput完全可控攻击者可以传入一个JSON对象其中包含__proto__、constructor等键虽然这在Go JSON中通常不会导致原型污染但需注意或者尝试触发非预期的类型转换导致程序崩溃或逻辑错误。Go语言本身没有像PHP或Java那样丰富的反序列化 gadget chain但通过精心构造利用encoding/gob反序列化到interface{}时可以还原出自定义类型的对象如果该类型定义了GobDecode方法且方法内有危险操作就可能构成漏洞。一个CTF中常见的模式是“JSON参数污染”。例如一个结构体如下type User struct { IsAdmin bool json:“is_admin” Username string json:“username” }登录时你发送{“username”: “guest”, “is_admin”: false}。但如果你发送{“username”: “guest”, “is_admin”: true, “is_admin”: false}不同的JSON解析库或Go的encoding/json对重复键的处理可能是最后一个值生效。那么如果服务器逻辑是先创建一个User对象然后用传入的JSON覆盖其字段那么IsAdmin可能被设置为true。这取决于具体的代码逻辑需要仔细审计。5.4 漏洞点三文件操作与路径遍历Go中文件操作相关函数如os.Open、ioutil.ReadFile、http.ServeFile如果其参数通常是文件路径部分或全部来自用户输入且未进行严格的净化就可能造成路径遍历。审计时搜索这些函数调用并向上追踪参数来源。例如func downloadHandler(w http.ResponseWriter, r *http.Request) { file : r.URL.Query().Get(“file”) http.ServeFile(w, r, “./public/”file) }这里用户可以通过file../../etc/passwd来读取系统文件。正确的做法是使用path.Join和path.Clean或者使用filepath.Rel来确保文件路径在允许的根目录之下。5.5 漏洞点四命令行注入虽然Go的exec.Command函数对参数进行了较好的处理与system()或popen()不同但如果不小心使用bash -c或类似的shell来执行命令且用户输入进入了命令字符串仍然存在风险。例如cmd : exec.Command(“sh”, “-c”, “ls ” userDir)如果userDir可控输入/tmp; cat /flag就会执行注入的命令。安全的做法是避免使用shell直接将参数作为字符串切片传递给exec.Command如exec.Command(“ls”, userDir)。但即使这样如果userDir是一个绝对路径或包含特殊字符也可能有非预期行为最佳实践是对输入进行严格的白名单过滤。6. 实战演练从审计到利用的完整链条假设在“BabyGo”源码中我们发现了如下可疑代码位于handlers/admin.gofunc AdminDebug(w http.ResponseWriter, r *http.Request) { sess, _ : store.Get(r, “session”) if auth, ok : sess.Values[“authenticated”].(bool); !ok || !auth { http.Error(w, “Forbidden”, 403) return } cmdStr : r.URL.Query().Get(“cmd”) // 危险直接拼接命令 out, err : exec.Command(“sh”, “-c”, “ping -c 1 ” cmdStr).CombinedOutput() if err ! nil { http.Error(w, err.Error(), 500) return } w.Write(out) }这是一个需要认证的管理员调试接口但存在命令注入。我们的目标是1. 绕过认证2. 注入命令读取Flag。步骤1认证绕过分析检查Session管理。可能在main.go中发现Session密钥硬编码在代码中store sessions.NewCookieStore([]byte(“weak_secret_here”))。由于密钥已知我们可以伪造一个Session Cookie将authenticated设置为true。使用Go编写一个小程序或者利用工具如flask-unsign如果格式兼容来生成签名的Cookie。步骤2命令注入利用认证绕过后访问/admin/debug?cmd127.0.0.1应该能执行ping -c 1 127.0.0.1。为了执行任意命令我们需要分隔命令。在Unix shell中分号;、与号、管道|、反引号“”都可以用。尝试/admin/debug?cmd127.0.0.1; cat /flag如果成功响应中会包含ping的结果和flag的内容。如果存在空格或特殊字符被过滤可以尝试使用${IFS}代替空格或者使用Base64编码配合解码执行/admin/debug?cmdecho${IFS}Y2F0IC9mbGFnCg|base64${IFS}-d|sh步骤3获取反向Shell如果需要如果只需要读取文件cat就够了。但如果需要更深入的交互可以尝试上传二进制文件或获取反向Shell。由于题目环境通常隔离且可能有防火墙反向Shell不一定成功。更可靠的方式是使用curl或wget将flag文件外带到自己的服务器或者利用DNS外带数据。7. 常见问题排查与技巧实录在解这类Web题的过程中会遇到各种“坑”。这里记录几个典型问题和解决思路。问题1请求被拦截返回403或400错误。可能原因缺少必要的请求头如X-Requested-With、Content-Type、Token校验CSRF Token、请求方法不正确应用要求POST但用了GET。排查技巧先用浏览器正常操作一次用Burp记录下所有请求包括Headers、Cookie、Body。然后用Repeater重放这个请求确保一模一样。再逐步修改你需要测试的参数。问题2明明感觉漏洞存在但Payload不生效。可能原因Payload的编码问题。例如在URL参数中空格需要编码为%20或在JSON Body中特殊字符需要转义。服务端可能有多层解码。排查技巧尝试不同编码。对于JSON确保是有效的JSON格式双引号、无尾随逗号。使用Burp的“Decoder”工具进行编码/解码转换。查看服务器返回的错误信息有时会提示问题所在。问题3速率限制太严格无法爆破。可能原因基于IP的限速太严或者需要验证码。绕过思路寻找限速逻辑的漏洞。例如是否通过X-Forwarded-For头来识别IP如果是可以尝试伪造该头。限速是否基于某个Token而这个Token可以被重置或重复使用是否在成功一次后限速会重置仔细分析整个交互流程的每一个环节。问题4Go SSTI测试Payload没反应。可能原因使用的是html/template它自动转义了HTML字符且函数调用受限或者模板变量作用域内没有可用的危险方法/属性。深入测试尝试注入{{.}}查看整个作用域对象。如果返回了结构体内容仔细研究其字段和方法名。尝试{{.MethodName}}调用无参数方法。查看题目是否引入了自定义的模板函数在代码中搜索Funcs方法。有时SSTI的利用点不在于RCE而在于信息泄露比如通过{{.}}泄露数据库连接字符串、内部文件路径等。问题5文件读取漏洞存在但读不到/flag或/etc/passwd。可能原因题目环境是容器Flag可能放在非标准路径如/run/secrets/flag、/flag.txt、/app/flag或者环境变量中。技巧先尝试读取/proc/self/environ获取所有环境变量。读取/proc/self/cmdline查看启动命令。读取/etc/hosts查看网络配置。如果题目提供了Dockerfile一定要仔细看Flag的路径和生成方式很可能写在里面。8. 工具链与自动化脚本心得手工测试是基础但适度的自动化能极大提高效率尤其是在CTF比赛的时间压力下。Burp Suite 自定义插件如Turbo Intruder用于爆破、参数枚举、Payload批量测试。对于“电子木鱼”的并发请求Turbo Intruder就比Intruder更高效。Python requests库编写自定义的漏洞利用脚本。对于需要多步操作如先登录获取Session再触发漏洞的题目用脚本可以稳定复现。浏览器开发者工具 Overrides 功能对于前端逻辑漏洞直接在本地修改并保存JS文件刷新页面即可测试无需每次手动在Console里输入。Go 语言本身如果题目是Go写的可以本地搭建环境导入题目源码进行调试。用dlv或gdb调试可以深入理解程序逻辑尤其是反序列化漏洞的利用链构造。最后分享一个我个人在CTF中的习惯每做一道题尤其是难题赛后一定要写完整的Writeup。这个过程能强迫自己把模糊的思路理清把零散的知识点串联起来。就像这次对VNCTF 2023三题的分析写出来之后对游戏逻辑漏洞、客户端信任漏洞、Go语言安全特性的理解比单纯解出题目时要深刻得多。遇到类似的场景反应速度也会更快。安全技术的学习三分靠看七分靠练而总结则是把练习成果固化的最好方式。
