tamakyi
307bd94ed1
线上验收发现两个「能被指纹识别」的破绽，都不影响原有功能但削弱伪装： 一、/xmlrpc.php 回的是 HTML 登录页（P1） 我们自己发的响应头里就有 X-Pingback: /xmlrpc.php —— 扫描器顺着跟过来， 一看是 HTML 就知道整站是假的（真实 WordPress 在这里回 text/xml）。 更可惜的是 system.multicall 这条通道被浪费：一次请求能带上千组用户名/密码、 且绕开登录页限速插件，是 WP 爆破里产出最高的入口。 新增 xmlrpc.go： - 非 POST → 405 + fault「XML-RPC services are disabled on this site.」（与真实 WP 一致） - POST methodCall → 200 + fault「Incorrect username or password.」（不区分用户是否存在） - POST system.listMethods → 200 + 方法列表（枚举类工具靠它确认对面是真 WP） - 凭据提取刻意不上 encoding/xml（蜜罐被高频命中）：抓所有 <string>、剔除 methodName 与站点 URL 后两两配对。wp.getUsersBlogs 的 blog_id 若是短数字会让 配对错位一位，故「奇数长度 + 首项短数字」时丢首项；另外原始串全量写进 fields（xmlrpc.0/1/…），配对失败也不丢原文。 multicall 的第一组进标准字段，其余进 cred2/cred3… —— 一个用户名配一长串 密码是常见字典形态，只留第一组等于丢掉整份字典。 - 封禁与表单提交同规则：带凭据走 RecordHoneypot（立即封），否则走常规阈值。 二、进入页面的隐藏值每次请求都一样（P2） 两次请求拿到同一个 pma token / csrf_token / X-Jenkins-Session，任何脚本都能 判定对面是伪造的。改为按请求生成 32 位 hex（math/rand/v2 —— 这些是假 token， 不需要不可预测，只需要每次不同；crypto/rand 在 Windows 要走系统调用，贵一个量级）， 页头、hidden 与 Set-Cookie 共用同一套。 顺带： - X-Pingback 改绝对地址（$base/xmlrpc.php）。真实 WP 给绝对 URL，相对路径本身 就是破绽；没配 external_url 时干脆不发这个头。 - Cache-Control 从 no-store 改 no-cache, must-revalidate, max-age=0 （no-store 更像安全设备/代理加的，不像登录页）。 - Grafana / GitLab 补上真实产品会种的会话 cookie（grafana_sess、_gitlab_session）。 - Match 增加 .php 变体兜底：清单里是 /phpinfo，扫描器打 /phpinfo.php， 原来漏掉 → 302 回首页，等于明确告诉对方「这个文件不存在」。 测试：xmlrpc_test（IsXMLRPCPath / getUsersBlogs / multicall / 数字 blog_id / 非 XML-RPC body / fault 与 listMethods 输出）、family_test（动态 token 两次不同且 是合法 hex、X-Jenkins-Session 与 correlation_id 动态、Pingback 绝对地址与缺省不发、 所有家族渲染后不残留 $ 占位符）、route 层（POST multicall 捕获凭据 + 立即封 + 回 text/xml；GET 回 405 fault 而非登录页）、honeypot（.php 变体命中且不牵连业务路径）。 四处变异验证均按预期变红：固定 token、xmlrpc 分支失效、Pingback 退化成相对路径、 .php 兜底失效。 性能：RenderFamily 3.7µs→4.18µs、2→3 allocs（多的一次是 hex 编码）， AssetFor 仍 0 分配。
狼的提问箱
匿名提问箱 / Anonymous Question Box
基于原版NekoBox做了一些微小的修改。主要体现在：
- 率先引入二维码访问，同时增加更多自定义可行性，方便自行创作。
- 添加探索页面，允许用户自行选择添加标签并展示，为陌生人提问创造可能。
- 稍微调整了屏蔽词策略。
截图
QRcode
Commit with picture
Explorer
安装
需求
从源码编译
git clone https://github.com/tamakyi/TamaBox.git
cd TamaBox
go build -o TamaBox
编辑配置文件
cp conf/app.sample.ini conf/app.ini
运行
./TamaBox web
架构
NekoBox 使用 GitHub Actions 进行持续集成和部署。
当用户访问 NekoBox 时，请求将会被发送至阿里云 CDN，CDN 的访问日志将会被实时推送到阿里云日志服务 (SLS)。日志数据将在 SLS 中存储 180 天，用于审计。
用户的信息、提问和回答将被存储在 MySQL 数据库中。
用户的会话、CSRF 令牌和电子邮件验证令牌将被暂时存储在 Redis 中。
用户的整个请求和响应链路将被上传到 Uptrace 用于调试。这些数据将被储存 30 天。管理员可以使用用户提供的 TraceID
来追踪查询指定的请求。
当用户提交提问时，问题的内容将被发送到七牛文本审查服务进行审查。如果提问内容存在问题，该内容将被发送到阿里云文本审查服务进行二次审查。 如果内容审查仍未通过，该提问将被拒绝发送。这是由于七牛文本审查服务不是很准确，一些非冒犯性的内容可能被七牛文本审查误报。
当用户收到新的提问时，阿里云邮件服务（DM）会向用户的邮箱发送一封邮件。
你可以在主页查看 NekoBox 的更新日志，也欢迎访问赞助页面来打钱支持 NekoBox。 更新日志和赞助商名单存储在独立部署的 Pocketbase 服务中。
开源协议
MIT License
备注
- 基于原版Nekobox修改，基本与原版无异，主要是添加了个人主页二维码和首页统计数，并修改了部分适合自己的参数。