免责声明：本文为个人技术学习与工程实践笔记，所涉操作仅应在获得授权的环境中进行。因不当使用造成的后果由使用者自行承担。
先作记录：团队个人赛已进入线下环节。本次队友出了一道题 signin，在此致谢。
希望今年的线下赛不必像去年那般，只能靠自己一个人输出
2022/9/25
比赛结束，未获得名次。题目质量不佳：搜索框参数被直接送入命令执行链路，这种设计在正常开发中很难出现，也是本题唯一的入口点（整体更接近 Misc 类题目）。此外，该 XSS 检测机器人的判定逻辑也值得商榷：它迟迟未访问到构造的页面，主办方称一分钟访问一次，可记录显示访问者全部是队友，这并不合理，其触发机制是否存在未公开的额外条件值得怀疑。
（归根结底仍是自身水平有限，此处不再展开）
另外，比赛环境确实糟糕。排在我前面的队伍也很不幸，开局前一小时始终没能连上靶场；起初我还在暗自庆幸他们连不上，后来自己也遭遇了同样的问题，比赛最终推迟一个小时。有些队伍的靶场能够正常使用：其他队伍卡在原地，他们却在一题接一题地作答。
防御启示
- 外部输入不得进入命令执行与表达式求值链路：本题把搜索框参数直接用于触发命令执行，属于典型的设计缺陷。服务端应对所有外部输入做类型与取值白名单校验，禁止将输入拼接进 shell、SQL 或表达式求值过程，解析与执行应分离。
- 自动化组件必须具备可观测性：检测机器人未按声明频率访问，且访问来源无法与真实用户区分，问题因此无法定位。此类组件应记录时间、来源与判定依据，并对外暴露健康状态，否则异常只能靠猜测。
- 环境可用性是发布前的检查项：靶场连续一小时不可用导致赛程整体推迟，反映出缺少环境自检与容量规划。部署前应对登录、依赖服务与网络策略做健康检查，并准备回滚手段与备用环境。
- 日志留存是定责与复盘的前提：正因为保留了访问记录，才能发现机器人行为异常。业务侧应对关键操作留存带时间戳与来源标识的日志，并集中存放，避免被业务方随意修改或清理。
