bsm-infra/full
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
full/docs/audit/module-base-sender.md
yanweidong 63aeedc2fe docs: add per-module audit reports (18 modules) 
Add static security/quality audit reports for all 18 Go service modules under module/, plus a consolidated index (docs/audit/README.md) with per-module statistics, top risks, cross-module systemic defects and a phased TODO list (T1-T19). No production code is modified.
2026-09-14 22:16:27 +08:00

717 lines
62 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 审计报告：module/base/sender
## 1. 模块概览
`module/base/sender`（绝对路径 `D:\work\bsm-infra\full\module\base\sender`）是短信/邮件/验证码微服务，gRPC + grpc-gateway 双栈输出，业务面只有 3 个接口：
| 服务 | 方法 | proto 定义 | HTTP 路径（生成代码实际值） |
|------|------|-----------|------------------------------|
| `sender.Sms` | `Send` | `proto/sms.proto:7` | `POST /sender.Sms/Send` |
| `sender.Sms` | `Verify` | `proto/sms.proto:8` | `POST /sender.Sms/Verify` |
| `sender.Mail` | `Send` | `proto/mail.proto:7` | `POST /sender.Mail/Send` |
请求体完全由调用方控制：`provider / sign_name / template_code / phone / is_gen_code / paramters`（`proto/sms.proto:12-19`）、`provider / template_key / to / is_gen_code / paramters`（`proto/mail.proto:11-17`）。
运行时形态有两种：
1. **独立进程**：`cmd/main/main.go` → `server.New(nil)` + SDK `core/service.New(...)`，配置取 `etc/sender_{dev,test,prod}.yaml`（gRPC 12208 / Gateway 12207）。
2. **聚合进程**：`pkgs/all` 通过 `moduleService.Expose(...)` 挂载（`pkgs/all/internal/service/sender.go:10-22`），配置取 `pkgs/all/etc/default_dev.yaml` 的 `Sender:` 段（`pkgs/all/etc/default_dev.yaml:98-118`）。
关键依赖：Redis（验证码/黑名单/计数）、PostgreSQL（邮件模板 `sender_template`）、阿里云短信 SDK（`dysmsapi-20180501/v2`）、腾讯云短信 SDK、`net/smtp`（邮件为**手写 SMTP 会话**，不走 SDK）。
## 2. 审计范围与方法
**纳入范围**（全部通读，共 39 个文件）：
- 非 pb Go 文件 18 个：`cmd/cli/main.go`、`cmd/main/main.go`、`internal/config/config.go`、`internal/excode/ex.go`、`internal/impl/{impl,provider}.go`、`internal/logic/mail/send.go`、`internal/logic/sms/{const,send,verify}.go`、`internal/models/sender_template.go`、`internal/server/{mail_server,new,sms_server}.go`、`service/{dependencies,expose}.go`、`test/grpc/{mail,sms}_test.go`。
- pb 生成代码 7 个（只核 HTTP 路由与字段语义，不逐行审）：`pb/*.pb.go`、`pb/*.pb.gw.go`、`pb/*_grpc.pb.go`。
- 配置：`etc/sender_{dev,test,prod}.yaml`、`etc/supervisor.bsm-apps-sender.conf`；proto 3 个；`README.md`、`UPGRADE_SUMMARY.md`。
- 必要的外部证据链（只读）：`pkgs/all`（聚合装配与鉴权中间件）、`D:\work\bsm-sdk\core`（该模块 `go.mod:90` 的 `replace` 目标：`conf`、`service`、`cache/redis`、`with`、`database`）、Go 标准库 `net/mail`、`github.com/alibabacloud-go/dara`。
**方法**：read/grep/glob 静态通读 + 全仓库交叉引用检索（确认计数器、黑名单、验证码 key 的所有读写点）+ 静态检查：
- `gofmt -l .` → **无输出，exit 0**（格式干净）。
- `go vet ./...` → **无输出，exit 0**（无可疑构造告警；`rand.Seed` 未被告警）。
- 未做动态验证：本机无 Redis/PG/短信账号，未实跑服务，也未执行集成测试（需 `-tags integration` 且指向真实线上地址，会发真实短信/邮件）。
**未纳入**：`api.apinb.com` 网关、`bsm-apps` 网关侧鉴权实现（不在本工作区），因此网关对 etcd 匿名列表的实际执行效果标注为「推测」。
## 3. 问题清单
### P0
#### 1. 短信/邮件发送接口无任何鉴权与调用方归属校验，且配置把发送接口显式声明为匿名
- **位置**：`module/base/sender/internal/logic/sms/send.go:26-39`、`module/base/sender/internal/logic/mail/send.go:22-39`、`module/base/sender/etc/sender_prod.yaml:15-18`、`module/base/sender/internal/server/new.go:23`、`module/base/sender/cmd/main/main.go:29,40`
- **证据**：
```go
// sms/send.go:26-31 —— 入参只有手机号校验，没有任何身份/权限/来源校验
func Send(ctx context.Context, in *pb.SmsSendRequest) (reply *pb.SmsReply, err error) {
var smsCode string
if in.GetPhone() == "" || !VerifyPhone(in.GetPhone()) {
return nil, excode.ErrPhone
}
```
```go
// sms/send.go:114-118 —— 签名与模板完全由请求方指定，直接下发到阿里云
"SignName": tea.String(cast.ToString(args.SignName)),
"TemplateCode": tea.String(cast.ToString(args.TemplateCode)),
```
```yaml
# etc/sender_prod.yaml:13-18 —— 三个接口被配置为匿名
MicroService:
Enable: false
Anonymous:
- sender.Mail.Send
- sender.Sms.Send
- sender.Sms.Verify
```
```go
// internal/server/new.go:21-23 —— 独立进程 gRPC 无任何 UnaryInterceptor
standalone := grpcServ == nil
if standalone {
grpcServ = grpc.NewServer()
```
```go
// internal/logic/mail/send.go:26-31 —— 邮件同样无鉴权，收件人与模板可选任意值
if in.GetTemplateKey() == "" || provider == "" || in.GetTo() == "" {
return nil, errcode.ErrInvalidArgument
}
cfg, ok := config.Spec.SMTP[provider]
```
- **影响**：
- **独立部署**：gRPC（`grpc.NewServer()` 无拦截器）与 HTTP 网关均无鉴权代码，任何能连到 12207/12208 的人都可以 `SignName` 填平台签名、`PhoneNumbers` 填任意手机号、`TemplateCode` 填任意模板，由平台账号付费下发 → 短信轰炸、费用损失，并可用平台签名发钓鱼/诈骗短信（`paramters` 内容也完全可控，见 `sms/send.go:107-109`）。
- **聚合部署**：`pkgs/all/etc/default_dev.yaml:24-44` 的 `Authorization.Anonymous` 未包含 sender 三个方法，因此需要 JWT——但 `pkgs/all/internal/server/authorization.go:42-53` 只校验 token 有效性，**不校验角色、租户，也不校验手机号是否属于该用户**，所以任意注册用户（passport 注册即可拿到 JWT）都能给任意手机号发短信/给任意邮箱发任意模板邮件。
- etc 中 `Anonymous: sender.Sms.Send/Verify/Mail.Send` 表明部署意图本身就是不留鉴权；`api.apinb.com` 网关会读取该 etcd 匿名列表决定是否放行（**推测**：该网关实现不在本工作区，`D:\work\bsm-sdk\core\service\register.go:95-121` 只负责把列表写进 etcd）。当前配置 `Enable: false`（`sender_prod.yaml:14`）表示连注册都不做。
- **建议**：
1. 模块内做兜底鉴权：gRPC `UnaryInterceptor` + gateway middleware 校验调用方身份（服务间 mTLS/内部 token，或 `authorization` metadata + 业务侧校验手机号是否属于该 user_id）。
2. 从 `MicroService.Anonymous` 中**移除** sender 三个方法；`Anonymous` 只保留真正公开的登录类接口。
3. 禁止请求方自由指定 `sign_name` / `template_code`：改为内部枚举（模板白名单表），或由服务端根据业务场景（登录/注册/改密）决定签名与模板；`paramters` 只允许白名单 key + 长度/字符集校验。
#### 2. 每日发送上限的计数器从未写入 —— 限额完全失效（无 TTL、非原子）
- **位置**：`module/base/sender/internal/logic/sms/send.go:41-51`、`module/base/sender/internal/logic/sms/const.go:7`
- **证据**：
```go
// sms/send.go:42-51 —— 只读计数，全仓库无任何 INCR/SET 写入该 key
limitKey := LimitCacheKey + time.Now().Format(FormatDay) + in.GetPhone()
twice, err := impl.RedisService.Client.Get(impl.RedisService.Ctx, limitKey).Int()
if err != nil && !errors.Is(err, redis.Nil) {
return nil, errcode.ErrRedis
}
if twice > config.Spec.Code.MaxSentLimit {
return nil, excode.ErrSentLimit
}
```
全仓库检索确认该 key 只有这一个读取点（无写入、无 TTL、无 `INCR`）：
```
module\base\sender\internal\logic\sms\const.go:7: LimitCacheKey = "/SMS/LimitCacheKey/"
module\base\sender\internal\logic\sms\send.go:42: limitKey := LimitCacheKey + time.Now().Format(FormatDay) + in.GetPhone()
```
- **影响**：`Get` 对不存在的 key 返回 `redis.Nil`，`Int()` 得到 `0`，`0 > 5` 恒为 false → **`Code.MaxSentLimit`（dev/prod/test 均为 5）永远不会生效**，同一手机号可被无限次发送；叠加问题 1（无鉴权/任意用户可调用），攻击者可对任意号码做无限短信轰炸，直接产生费用。邮件侧连这段死代码都没有（`mail/send.go` 全文件无频控）。
- **建议**：改为原子自增 + 首次写入设置过期：
```go
n, err := cli.Incr(ctx, limitKey).Result()
if n == 1 { cli.Expire(ctx, limitKey, 24*time.Hour) }
if n > max { ... }
```
并把「检查-自增-发送」改为「先占配额再发送，发送失败回滚（DECR）」。同时补：分钟级/小时级频控、同手机号 60s 重发间隔、IP/账号维度频控、图形验证码前置。
#### 3. `Sms.Verify` 无尝试次数限制，且「一次性失效」逻辑写反（成功不删、失败才删）
- **位置**：`module/base/sender/internal/logic/sms/verify.go:12-39`
- **证据**：
```go
// verify.go:27-35 —— 校验通过后直接返回，不删除 key；不通过反而删除 key
if code == in.Code {
return &pb.SmsReply{Reply: "true"}, nil
}
//verify pass ; delete the requestId
impl.RedisService.Client.Del(impl.RedisService.Ctx, key)
```
```go
// verify.go:12-19 —— 除空值外无任何次数/频率限制，也无失败计数
if in.GetCode() == "" { return nil, excode.ErrCode }
if in.GetPhone() == "" { return nil, excode.ErrPhone }
```
- **影响**：
- **可爆破**：6 位验证码仅 10^6 组合，`Verify` 无失败计数、无锁定、无验证码图片，单个验证码有效期 `Code.Expire=300s`（`etc/sender_prod.yaml:45`），以 Redis GET 的速率完全可以在窗口内穷举 → 结合任意注册用户即可调用的现状（问题 1），可用于账号接管（该 key 与 `mgt` 忘记密码流程共用，见下）。
- **可重放**：成功后 key 不删除，同一验证码在 300s 内可被无限次重复使用（一次性语义缺失）。
- **可被 DoS**：代码注释写「verify pass ; delete」，实际在**校验失败**分支删除，任何知道手机号的人只要调一次 `Verify` 传错码，就能把该手机号的验证码从 Redis 中删除，使合法用户/其他业务（如 `mgt` 忘记密码）永远无法完成校验——且该 key 前缀是共享的：`module/base/mgt/internal/types/vars.go:4` 与 `module/base/sender/internal/logic/sms/const.go:5` 同为 `/SMS/Code/`，`module/base/mgt/internal/logic/pub/forget.go:57-73` 正是读这个 key 做密码重置。
- **建议**：
1. 成功即删（`DEL` 放在 `code == in.Code` 分支内），实现一次性语义；失败分支**不要**删 key。
2. 增加失败计数（同一 phone 或同一 phone+code 维度），如 `INCR /SMS/VerifyFail/<phone>`，超过 5 次即删除验证码并锁定 10 分钟；计数器与验证码同 TTL。
3. 校验用 `GETDEL`（`redis.Client.GetDel`）保证「校验+删除」原子，避免并发重放。
4. 校验接口也纳入问题 1 的鉴权与频控，并对同一手机号做全局失败率限制。
#### 4. 验证码使用 `math/rand` 且以时间戳播种，可预测
- **位置**：`module/base/sender/internal/logic/sms/send.go:161-176`
- **证据**：
```go
// send.go:166-173
l := 10
numeric := []byte{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
rand.Seed(time.Now().UnixNano())
... fmt.Fprintf(&sb, "%d", numeric[rand.Intn(l)])
```
- **影响**：`math/rand` 是可确定性伪随机源（非密码学安全），且用 `time.Now().UnixNano()` 播种使种子与「发送时刻」强相关。攻击者若能触发一次发送（问题 1 允许任意触发）并知道大致时间，就能在纳秒级候选窗口内穷举 `rand.Seed` 复现同一序列，直接算出验证码 → 验证码不再提供任何安全强度（尤其当验证码用于登录/改密时构成账号接管）。此外 `rand.Seed` 修改全局源，在并发请求下还会与其他使用全局 `math/rand` 的代码相互干扰。
- **建议**：改用 `crypto/rand`：`crypto/rand.Int(rand.Reader, big.NewInt(10))` 逐位生成，或一次性生成 `[0,10^n)` 均匀随机数并零填充；禁止使用 `math/rand` 的全局源，也禁止 `time` 相关播种。
### P1
#### 5. 腾讯云 `TencentSender` 是空实现，却返回 `(nil, nil)` 表示成功
- **位置**：`module/base/sender/internal/logic/sms/send.go:151-153`（调用点 `send.go:82-86`）
- **证据**：
```go
// send.go:151-153 —— 直接返回 nil,nil，不发任何请求
func TencentSender(args *pb.SmsSendRequest) (map[string]any, error) {
return nil, nil
}
```
```go
// send.go:82-86 —— 只要 Provider.Tencent 非 nil 就会走空实现，err==nil
case "tencent":
if impl.Provider.Tencent == nil { return nil, excode.ErrProviderIsNil }
result, err = TencentSender(in)
```
- **影响**：`impl.Provider.Tencent` 在 `internal/impl/provider.go:46-47` 已真实初始化（`NewTencent` 建了 SDK 客户端），因此只要配置了 `SMS.tencent`，`provider=tencent` 的调用会**返回成功**（`Reply: "null"`，因为 `json.Marshal(nil map)` → `null`），而短信根本没有发出：业务侧拿到成功却永远收不到验证码，且无任何日志/埋点暴露。同时 README:9 宣称「多服务商支持：阿里云短信、腾讯云短信」。精确空实现位置：`internal/logic/sms/send.go:151-153`。
- **建议**：要么用 `impl.Provider.Tencent` 真正实现 `SendSms`（`sms/v20210111` 的 `SendSms`，把 `SignName/TemplateCode/TemplateParamSet/PhoneNumberSet` 传进去，并保留 `SerialNo` 做幂等），要么删除 `tencent` 分支 + `NewTencent` + 配置项，并同步修正 README。在未实现期间必须返回 `excode.ErrNotProvider`，禁止静默成功。
#### 6. 邮件实际只实现了 `qq` 一个渠道，但配置结构、README 与测试都宣称支持多渠道；且 `is_gen_code` 被完全忽略
- **位置**：`module/base/sender/internal/logic/mail/send.go:55-60`、`internal/logic/mail/send.go:31-34`、`test/grpc/mail_test.go:37`、`README.md:18,262-287`
- **证据**：
```go
// mail/send.go:55-60 —— 只有 qq 分支；QQ() 本身其实与 qq 无关（通用 SMTP）
switch provider {
case "qq":
err = QQ(cfg, tmpl, in.GetTo(), tplRecord.Subjet, in.GetParamters())
default:
return nil, excode.ErrNotProvider
}
```
```go
// mail/send.go:31-34 —— SMTP 配置是 map，看起来支持多渠道路由，但 gmail 会先在这里 404
cfg, ok := config.Spec.SMTP[provider]
if !ok || cfg == nil { return nil, excode.ErrProviderIsNil }
```
```go
// test/grpc/mail_test.go:31-38 —— 官方测试用例自己用的是 gmail，必然失败
req := &pb.SendMailRequest{ TemplateKey: "default", To: "271055687@qq.com", Paramters: ...,
Provider: "gmail" }
```
- **影响**：
- 配置（`SMTP: map[string]*SmtpConf`，`internal/config/config.go:26,31-38`）、`withProvider` 的 `google` 分支（`impl/provider.go:35-36`）、README:18/262-287 的「Gmail 等主流邮箱」以及扩展指引，都指向多渠道；实际只有 `qq`。`pkgs/all/etc/default_dev.yaml:99-106` 的渠道名是 `default`，在 `switch` 里同样落到 `ErrNotProvider`。多渠道抽象是假的。
- `SendMailRequest.IsGenCode`（`proto/mail.proto:15`）在 `mail.Send` 全文件中**从未被读取**：既不生成验证码，也不写 Redis。调用方按 protobuf 注释「是否生成验证码」传 `is_gen_code=true` 时会以为验证码已生成并入库，实际邮件模板里的 `{{.code}}` 会是空值，且模块内也不存在任何 `Mail.Verify` 接口可以校验邮件验证码。
- **建议**：把 `QQ()` 改名为 `SMTPSender()` 并去掉 `switch`（直接按 `provider` 取配置），或按真实渠道补齐实现；`is_gen_code` 要么实现（生成 + `KeyPrefix` 落 Redis + 后续校验），要么从 proto 与文档中删除该字段。
#### 7. 阿里云短信调用无超时、未传递 ctx，可无限阻塞 gRPC 处理协程
- **位置**：`module/base/sender/internal/logic/sms/send.go:123-126,148`
- **证据**：
```go
// send.go:123-126,148 —— runtime 全空（未设 ReadTimeout/ConnectTimeout），且用的是无 ctx 的 CallApi
runtime := &dara.RuntimeOptions{}
request := &AliYunClient.OpenApiRequest{ Query: AliYunUtil.Query(params) }
...
return impl.Provider.Aliyun.CallApi(clientParams, request, runtime)
```
证据链：SDK 侧 `darabonba-openapi/v2@v2.1.12/client/client.go:163-164` 用 `Default(IntValue(runtime.ReadTimeout), IntValue(client.ReadTimeout))` 取值，而模块既没在 `runtime` 也没在 `AliYunClient.Config`（`internal/impl/provider.go:68-71` 只设 `Endpoint/Credential`）设置超时 → `tea@v1.5.3/dara/core.go:354` 得到 `httpClient.Timeout = 0`，即 **Go 语义下的「无超时」**。该 SDK 另提供 `CallApiWithCtx`（`darabonba-openapi/v2@v2.1.12/client/client_context_func.go:1330`），模块未使用。
- **影响**：阿里云侧变慢/挂死时，HTTP 请求永不超时，gRPC handler 协程（含 `ctx` 已取消的请求）会一直占用内存与连接；`ctx` 未下传意味着调用方断连/超时也无法取消，容易被放大成协程堆积 → 服务级联不可用。同时无重试、无熔断、无降级。
- **建议**：`runtime := &dara.RuntimeOptions{ConnectTimeout: dara.Int(3000), ReadTimeout: dara.Int(5000), Autoretry: dara.Bool(true), MaxAttempts: dara.Int(2)}`，改用 `CallApiWithCtx(ctx, ...)`，并用 `context.WithTimeout` 包住整个 handler；对超时/限流类错误做业务化错误码与告警。
#### 8. SMTP 会话：成功路径不关闭连接（每封邮件泄漏一个 TLS 连接）、无 dial 超时、同步阻塞无重试
- **位置**：`module/base/sender/internal/logic/mail/send.go:76-86,140-151`
- **证据**：
```go
// mail/send.go:77-82 —— tls.Dial 无 Dialer/超时参数，可长期阻塞
conn, err := tls.Dial("tcp", fmt.Sprintf("%s:%d", cfg.Endpoint, cfg.Port), &tls.Config{
ServerName: cfg.Endpoint, MinVersion: tls.VersionTLS12, InsecureSkipVerify: false })
```
```go
// mail/send.go:140-151 —— 写入完成后直接 return nil：没有 client.Quit()，也没有 conn.Close()
if _, err := writer.Write([]byte(mailBody)); err != nil { client.Close(); ...; return err }
if err := writer.Close(); err != nil { client.Close(); ...; return err }
return nil
```
- **影响**：
1. **连接泄漏**：成功路径既不 `client.Quit()` 也不 `conn.Close()`，TCP/TLS 连接只能等 GC/finalizer 回收；每封成功邮件泄漏 1 个 fd（另有 `defer writer.Close()` 与显式 `writer.Close()` 的双重关闭）。在被批量调用时迅速耗尽本地端口/fd，表现为「突然发不出邮件」。
2. **无超时**：`tls.Dial` 使用默认 dialer（无超时），SMTP 端静默挂起会永久阻塞 gRPC 协程，且 `ctx` 参数在 `mail.Send` 中完全未使用。
3. 同步发送：handler 内直接等待外部 SMTP 往返（含握手+认证+多轮命令+DATA），无队列、无并发上限、无重试与退避；高峰时 goroutine 堆积。
- **建议**：`defer func(){ client.Quit(); conn.Close() }()` 或统一 `defer client.Close()`；dial 用 `net.Dialer{Timeout: 5*time.Second}` + `tls.DialWithDialer`，并给整个会话加 `conn.SetDeadline`；发送改投内部队列（异步 worker + 指数退避重试 + 失败落库），handler 只入队。
#### 9. SMTP 握手失败时对 nil 客户端调用 `Close()`，panic 崩溃进程
- **位置**：`module/base/sender/internal/logic/mail/send.go:89-94`
- **证据**：
```go
client, err := smtp.NewClient(conn, cfg.Endpoint)
if err != nil {
client.Close() // smtp.NewClient 失败时返回 nil,err → nil 解引用
fmt.Println("SMTP客户端初始化失败: ", err)
return err
}
```
（`net/smtp.NewClient` 在 greeting 读失败时 `return nil, err`；gRPC 默认**不 recover** handler panic，`internal/server/new.go:23` 也未加 recovery 拦截器，panic 会终止整个进程。）
- **影响**：SMTP 服务端 greeting 异常（网络抖动、网关拦截、端口写错、`.Endpoint` 配成 `smtp.gmail.com` 的 465/587 不匹配等）即可让 `Mail.Send` 触发 nil panic → 整个 sender（在聚合部署下是整个 `pkgs/all` 进程，因为共享同一 gRPC server）崩溃重启，属于可被外部依赖状态触发的可用性事故。
- **建议**：`if err != nil { _ = conn.Close(); return err }`；同时给 gRPC server 加 `grpc.ChainUnaryInterceptor(recoveryInterceptor)`，并在所有出错的 `Close()` 调用前判空。
#### 10. 敏感信息明文进入日志：验证码明文打印、DB/Redis 连接口令随启动日志输出
- **位置**：`module/base/sender/internal/logic/sms/send.go:96,146-147`、`module/base/sender/internal/impl/impl.go:26`、`module/base/sender/etc/sender_dev.yaml:7,10,32,41`
- **证据**：
```go
// sms/send.go:95-96 —— 返回体与 stdout 都包含模板参数（含验证码）
jsonBytes, _ := json.Marshal(result)
fmt.Println("短信发送结果:", string(jsonBytes))
// sms/send.go:146-147 —— 参数里 TemplateParam 就是 {"code": 验证码}，明文打到 stdout
fmt.Println("请求参数params为：", params)
```
```go
// internal/impl/impl.go:24-26 —— 传入的是带口令的完整 DSN
RedisService = with.RedisCache(config.Spec.Cache)
DBService = with.Databases(config.Spec.Databases, nil)
```
SDK 会把 DSN 原文打印出来：`with/databases.go:18`（`printer.Info("... Databases: %v", cfg)`）、`with/redis.go:14`（`printer.Info("... Cache: %s", cfg)`），而 DSN 形如 `etc/sender_dev.yaml:7,10`：`password=CHANGE_ME`、`redis://null:CHANGE_ME@...`。另外 `internal/impl/provider.go:60-61` 把 AK/SK 明文塞进凭据对象，配置文件中 `etc/sender_dev.yaml:40` 还提交了真实 AccessKeyId（`LTAI5tKEmKuuoixE4iw8NZbX`）与真实企业邮箱账号（`:31,33`）。
- **影响**：验证码明文进日志违反「验证码不得落日志」的基本要求（日志被读=验证码被读，直接绕过问题 3 的所有加固）；DB/Redis 口令、SMTP 口令、AK/SK 随启动日志与提交进仓库的配置文件扩散，属于凭据泄露面。日志还使用 `fmt.Println` 无结构、无级别、无请求 ID，无法审计追踪（supervisor 只做 stdout 重定向，见 `etc/supervisor.bsm-apps-sender.conf:8`）。
- **建议**：删除所有打印验证码/模板参数的语句，改为结构化日志（`slog`/项目 logger）并统一脱敏（手机号掩码、验证码/口令/AK 一律不打）；启动日志屏蔽 DSN 口令（`with` 层做 `***` 替换）；配置文件只留占位符，真实口令走环境变量/配置中心，并轮换已提交的 AccessKeyId 与邮箱授权码。
#### 11. 黑名单机制实际无效：无人写入、检查失败静默放行、相关配置项完全未使用
- **位置**：`module/base/sender/internal/logic/sms/send.go:37-39`、`internal/logic/sms/const.go:6`、`internal/config/config.go:55`
- **证据**：
```go
// sms/send.go:37-39 —— SIsMember 的 err 被丢弃（.Val() 只取布尔），Redis 异常时 fail-open
if impl.RedisService.Client.SIsMember(impl.RedisService.Ctx, BlackListCacheKey, in.GetPhone()).Val() {
return nil, excode.ErrInBlackList
}
```
全仓库检索 `/SMS/BlackList/` 只有这一个读取点，**没有任何写入/管理接口**；`Code.BlackListFilter`（`internal/config/config.go:55`，dev/prod/test 都配了 `- 127.0.0.1`）在整个模块中无任何引用。
- **影响**：黑名单只有在有人手工往 Redis set 里塞数据时才生效，代码层面没有任何维护入口，也无法审计；同时因为丢弃了 error，Redis 不可用时黑名单判断**静默放行**（应为 fail-closed 或至少告警）。README:12 宣称「黑名单过滤：支持手机号黑名单机制」，实际是一个空壳。
- **建议**：补齐黑名单管理能力（配置加载 `BlackListFilter` 到 Redis、或提供内部管理 RPC），检查失败按策略处理（Redis 错误时拒绝发送并告警），把 `SIsMember(...).Result()` 的错误显式判断。
#### 12. 验证码写入用 `SetNX` 但忽略返回值；用户传入的 `paramters["code"]` 会覆盖刚生成的验证码
- **位置**：`module/base/sender/internal/logic/sms/send.go:65`、`internal/logic/sms/send.go:102-109`
- **证据**：
```go
// sms/send.go:62-65 —— 生成后 SetNX，返回值与 err 都没看；已存在时写入失败但短信照发
smsCode = GenValidateCode(config.Spec.Code.Length)
expire := time.Second * time.Duration(config.Spec.Code.Expire)
impl.RedisService.Client.SetNX(impl.RedisService.Ctx, key, smsCode, expire)
```
```go
// sms/send.go:104-109 —— 先放生成的 code，再被请求参数覆盖
var templateParam = map[string]any{"code": code}
for key, val := range args.Paramters { templateParam[key] = val }
```
- **影响**：
1. `SetNX` 失败（同一手机号 300s 内二次发送）时，Redis 里仍是旧验证码，而用户手机收到的是**新验证码** → 用户永远无法通过校验，且没有任何错误返回；同时 `err` 被忽略，Redis 故障也无声。
2. 调用方只要在 `paramters` 里带 `code`（`send.go:66-72` 的非生成模式也需要它），就会覆盖模板里的验证码 → 下发的验证码与 Redis 中存储的验证码不一致（用户校验必失败），并且这个覆盖值完全由请求方决定（可用来在平台签名短信里塞任意内容，配合问题 1 构成钓鱼）。
- **建议**：写入改为 `Set(key, code, expire)`（或先 `GETDEL/DEL` 再 `Set`）并检查返回错误；把生成码与业务参数**显式隔离**：模板参数只从白名单 key 取值，`code` 由服务端唯一注入，禁止被 `paramters` 覆盖；`is_gen_code=false` 时也要明确「谁负责校验」或直接禁止该模式。
#### 13. 配置缺失即 panic：`Code` 段/Redis 未配置时空指针崩溃（无配置校验、无 recover）
- **位置**：`module/base/sender/internal/config/config.go:60-77`、`internal/logic/sms/send.go:45-57`、`internal/impl/impl.go:22-24`
- **证据**：
```go
// config/config.go:65-70 —— 只校验 Service/Cache，Code、SMS、SMTP 都没校验
Spec.Port = conf.CheckPort(Spec.Port)
Spec.BindIP = conf.CheckIP(Spec.BindIP)
conf.NotNil(Spec.Service, Spec.Cache)
```
```go
// sms/send.go:49,57 —— Code 为 nil 时直接解引用 panic
if twice > config.Spec.Code.MaxSentLimit {
if config.Spec.Code.Length < 4 || config.Spec.Code.Length > 10 {
```
- **影响**：`Code:` 段缺失（或 `Cache:` 为空导致 `with.RedisCache` 返回 nil，见 `with/redis.go:9-17`）时，**首个请求**就会 nil 解引用 panic；gRPC 无 recover（见问题 9）→ 进程退出。配置错误被推迟到运行时才以进程崩溃的形式暴露。
- **建议**：在 `config.New` 中用 `conf.NotNil(Spec.Code, Spec.SMS, Spec.SMTP)` 做启动期校验并为 `Length/Expire/MaxSentLimit` 设定安全默认值与边界（如 Expire>0、MaxSentLimit>0）；Redis/DB 客户端在 `NewImpl` 中判空并 fail-fast（带明确错误信息），而不是留到请求路径。
#### 14. 生产/测试配置不可用：`SMS.aliyun.Endpoint` 填成了 `smtp.gmail.com`，DB/Redis 指向本地且口令为 `CHANGE_ME`
- **位置**：`module/base/sender/etc/sender_prod.yaml:38,7,10`、`module/base/sender/etc/sender_test.yaml:37,7,10`
- **证据**：
```yaml
# etc/sender_prod.yaml:36-41 —— 阿里云短信的 Endpoint 是 gmail 的 SMTP 地址（复制粘贴错误）
SMS:
aliyun:
Endpoint: smtp.gmail.com
AccessKeyId: <your-access-key-id>
```
```yaml
# etc/sender_prod.yaml:4-10 —— 生产库/缓存仍是本地 CHANGE_ME + bsm_dev
Databases:
Driver: postgres
Source:
- host=127.0.0.1 user=postgres password=CHANGE_ME dbname=bsm_dev port=5432 sslmode=disable
Cache: redis://null:CHANGE_ME@127.0.0.1:6379/
```
- **影响**：prod/test 配置一旦被使用，阿里云短信请求会打到 `smtp.gmail.com`（签名/鉴权全部失败，短信全量不可用），DB/Redis 连接必然失败（`with.Databases` 直接 panic，见 `with/databases.go:13-15`）。配置与 README 的示例（README:88-92）也不一致。生产配置与开发配置几乎相同，说明该文件没有被真实部署验证过。
- **建议**：prod 配置改为真实 Endpoint（`dysmsapi.aliyuncs.com`）+ 密钥外置（环境变量/配置中心），数据库/缓存指向真实地址；在启动期对 `Endpoint` 做白名单校验（如必须匹配 `*.aliyuncs.com`），避免此类拼写错误静默上线。
#### 15. 接口返回语义与真实状态不一致：`Verify` 用 `Reply:"false"` + `err=nil`；`Send` 用 `"null"`/厂商业务错误当成功
- **位置**：`module/base/sender/internal/logic/sms/verify.go:37-39`、`internal/logic/sms/send.go:91-99`、`internal/logic/sms/send.go:151-153`
- **证据**：
```go
// verify.go:37-39 —— 校验失败时 err 为 nil，HTTP/gRPC 层面都是成功响应
return &pb.SmsReply{
Reply: "false",
}, nil
```
```go
// sms/send.go:95-99 —— 只要 SDK 没返回 error 就当作成功，reply 是原始响应体
jsonBytes, _ := json.Marshal(result)
fmt.Println("短信发送结果:", string(jsonBytes))
return &pb.SmsReply{ Reply: string(jsonBytes) }, nil
```
- **影响**：调用方只要按惯例判断 `err == nil`（或 HTTP 200）就会把「验证码错误」当成「验证通过」，这是典型的越权/接管风险点；`Send` 侧则可能把阿里云的业务错误（如 `isv.BUSINESS_LIMIT_CONTROL`、`isv.AMOUNT_NOT_ENOUGH`）与 `null`（腾讯空实现）都返回成成功。响应体直接回传云厂商原始 JSON，还会向调用方暴露账号/模板/请求 ID 等信息。
- **建议**：`Verify` 失败返回明确错误码（如 `excode.ErrCode` 或 `ErrExpired`），成功返回 `true` 或结构化结果；`Send` 应解析厂商返回并映射为统一结果结构（`ok/msg_id/code`），业务失败必须返回非 nil error；不要把厂商原始报文透传给调用方。
#### 16. 邮件发送无频控、无配额、无收件人限制
- **位置**：`module/base/sender/internal/logic/mail/send.go:22-45`（全文件无任何频控/黑名单/配额逻辑，对比 `sms/send.go:37-51`）
- **证据**：
```go
// mail/send.go:26-31 —— 仅校验非空与 SMTP 配置存在，之后直接查模板并发送
if in.GetTemplateKey() == "" || provider == "" || in.GetTo() == "" {
return nil, errcode.ErrInvalidArgument
}
cfg, ok := config.Spec.SMTP[provider]
```
- **影响**：任意可调用方（问题 1）都能以平台发件人身份向任意邮箱发任意模板邮件，无频控、无黑名单、无每日配额、无收件人域名限制 → 邮件轰炸，并直接损害企业邮箱域名的发信声誉（进入黑名单/SPF-DKIM 信誉下降），恢复成本极高。
- **建议**：与短信同样引入「配额 + 频控 + 黑名单 + 收件人白名单/域名策略」，并对同一 `to` 做 60s 重发间隔与幂等键去重。
### P2
#### 17. Provider 初始化失败直接 `panic`，无降级、无错误返回
- **位置**：`module/base/sender/internal/impl/provider.go:63-66,73-76,85-89`
- **证据**：
```go
// provider.go:63-66
akCredential, err := credentials.NewCredential(config)
if err != nil {
panic(err)
}
```
（同类：`dysmsapi.NewClient` 失败 `provider.go:73-76`；`TencentCloud.NewClient` 失败 `provider.go:85-89`。）
- **影响**：任一云凭据缺失/格式错误（例如 `AccessKeyId: <your-access-key-id>` 占位符，见问题 14）都会让服务在启动期直接 panic 退出，而不是「仅该渠道不可用」；`TencentSender` 是空实现却仍强制初始化腾讯客户端，扩大了崩溃面。缺少可观测的启动诊断。
- **建议**：`withProvider()` 返回 error 并在 `NewImpl` 中汇总上报；单渠道初始化失败只禁用该渠道（记录告警），或明确 fail-fast 但给出可读的配置错误信息。
#### 18. 请求路径中改写全局配置 `config.Spec.Code.Length`（数据竞争）
- **位置**：`module/base/sender/internal/logic/sms/send.go:56-59`
- **证据**：
```go
// 每次发送都在读路径上写全局配置
if config.Spec.Code.Length < 4 || config.Spec.Code.Length > 10 {
config.Spec.Code.Length = 6
}
```
- **影响**：并发请求下对全局配置做无锁写，`go test -race` 会直接报 data race；配置语义被运行时篡改，行为不可预期（也掩盖了问题 13 的配置错误）。
- **建议**：改为局部变量取默认值（`length := config.Spec.Code.Length; if length < 4 || length > 10 { length = 6 }`），配置只读；默认值与边界校验放启动期。
#### 19. 表结构迁移未生效：`sender_template` 需手工建表，否则邮件全部失败（迁移与启动耦合）
- **位置**：`module/base/sender/internal/models/sender_template.go:16-18`、`module/base/sender/internal/impl/impl.go:26`
- **证据**：
```go
// models/sender_template.go:16-18 —— 注册自动迁移
func init() { database.AppendMigrate(&SenderTemplate{}) }
```
但迁移入口条件不满足：`impl.NewImpl()` 调用 `with.Databases(config.Spec.Databases, nil)` 传 `nil` options（`internal/impl/impl.go:26`），SDK 默认 `IsAutoMigrate: false`（`D:\work\bsm-sdk\core\database\sql\postgresql.go:17`），而 `new.go:43-44` 仅在 `options.IsAutoMigrate` 为真时执行 `AutoMigrate`；同时命名策略是 `SingularTable: true`（`postgresql.go:39-41`），实际表名为 `sender_template`。
- **影响**：自动迁移永远不会执行，部署时若没有手工建 `sender_template` 表，`mail.Send` 会在 `impl.DBService.Where(...).First()` 处报错并被统一转换成 `ErrNotFound(1404,"template")`（`mail/send.go:43-46`），表现为「所有模板都不存在」，排查成本高；`AppendMigrate` 成为误导性死代码。
- **建议**：把建模迁移从进程启动解耦，改为显式迁移命令/脚本（`cmd/cli` 或 CI 步骤）并在文档中写明表结构；若坚持自动迁移，则显式传 `&types.SqlOptions{IsAutoMigrate: true}` 并明确告警。
#### 20. 邮件每次请求都查库 + 重新解析模板，且每次发送新建 TLS 连接（无缓存、无连接复用）
- **位置**：`module/base/sender/internal/logic/mail/send.go:42-52,76-86`
- **证据**：
```go
// mail/send.go:43-52 —— 每个请求一次 DB 查询 + 一次模板 Parse，无任何缓存
err = impl.DBService.Where("key=?", in.GetTemplateKey()).First(&tplRecord).Error
...
tmpl, err := template.New("page").Parse(tplRecord.Body)
```
- **影响**：模板是低频变更数据，却按请求查库并重新解析（HTML 模板解析是 CPU 密集操作），属明确的性能浪费；加之每次发送都新建 TLS 连接（无连接池/无长连接复用），单封邮件成本远高于必要值。`impl.MemorySerice`（go-cache）已初始化却从未使用（见问题 21），缓存条件其实已经具备。
- **建议**：用 `MemorySerice`/Redis 对模板做带版本的缓存（key = template_key，TTL 几十秒，或提供失效接口），并在发送侧复用 SMTP 连接（或至少限制并发连接数）。
#### 21. 死代码与空壳实现较多，容易误导后续开发
- **位置**：`internal/impl/provider.go:52-54`、`internal/impl/provider.go:20-25`、`internal/server/new.go:17,29`、`internal/impl/impl.go:16,22`、`internal/config/config.go:53-55`、`internal/excode/ex.go:8,11,14`
- **证据**：
```go
// provider.go:52-54 —— 永远返回 nil 的构造函数
func NewSMTP(conf *config.SmtpConf) *smtp.Client {
return nil
}
```
其余：`ProviderClient.Google/QQ`（`provider.go:22-23`）永远是 nil，`withProvider` 的 `google` 分支（`provider.go:35-36`）赋 nil；`Server.grpcConns`「连接池」声明并初始化但从未使用（`server/new.go:17,29`）；`MemorySerice`（`impl.go:16,22`，方法名本身是 `Service` 的拼写错误）从未使用；`Code.CokeyKey/GenerateCode/BlackListFilter`（`config.go:53-55`）无引用；`ErrAppName/ErrMustWhiteList/ErrExpired`（`ex.go:8,11,14`）无引用。
- **影响**：空实现与死配置让阅读者（以及 README 的扩展指引）以为多渠道/白名单/内存缓存已经可用，实际都没有落地；`NewSMTP` 返回 nil 若被启用还会立刻 nil 解引用。
- **建议**：删除或补齐：`NewSMTP` 及 `Google/QQ` 字段直接删除（邮件走 `SMTPSender` 统一实现）；`grpcConns` 删除；未使用的配置项与错误码删除或补上实现与测试。
#### 22. 错误被吞掉或错误映射失真
- **位置**：`internal/logic/sms/send.go:95,156`、`internal/logic/sms/send.go:37`、`internal/logic/mail/send.go:124,146-150`、`internal/logic/mail/send.go:43-46`
- **证据**：
```go
// sms/send.go:95 与 mail/send.go:124 —— 错误被丢弃
jsonBytes, _ := json.Marshal(result)
defer writer.Close() // 与 mail/send.go:146 的显式 Close 形成双重关闭
```
```go
// sms/send.go:155-158 —— regexp 的 error 被丢弃
result, _ := regexp.MatchString(`^(1[3|4|5|6|7|8|9][0-9]\d{4,8})$`, phone)
```
```go
// mail/send.go:43-46 —— DB 连接错误也被统一报成「模板不存在」
err = impl.DBService.Where("key=?", in.GetTemplateKey()).First(&tplRecord).Error
if err != nil { return nil, errcode.ErrNotFound(1404, "template") }
```
- **影响**：Redis/DB/SMTP 的真实故障被掩盖成语义错误的返回值（「模板不存在」「发送成功」），现场排查困难；`SetNX`、`SIsMember().Val()`、`json.Marshal`、`regexp` 的忽略错误在问题 11/12 中已有实际后果；`writer.Close()` 二次调用掩盖了第一次的错误。
- **建议**：统一 `if err != nil { return ... }` 处理并包装错误上下文；区分配置缺失（1404）与基础设施错误（5xx/`ErrDB`）；去掉重复的 `Close`。
#### 23. 缺可观测性与优雅退出：无结构化日志、无 recover、无健康检查、`defer srv.Stop()` 不可达
- **位置**：`module/base/sender/cmd/main/main.go:44-48`、`module/base/sender/internal/logic/sms/send.go:96`、`module/base/sender/internal/logic/mail/send.go:84,92,100`、`README.md:31,352,375-392`
- **证据**：
```go
// cmd/main/main.go:44-48 —— defer 注册在 Start() 之前，但 Start() 内部是 select{} 永不返回
defer srv.Stop()
srv.Start()
```
（SDK `D:\work\bsm-sdk\core\service\service.go:113-115` 的 `srv.Start()` 以 `select {}` 阻塞；`cmd/main` 也未注册 SIGTERM/SIGINT 处理，对比 `pkgs/all/cmd/main/main.go:46-53`。）
- **影响**：进程收到 supervisor 的 TERM 时不会优雅关闭（`etc/supervisor.bsm-apps-sender.conf` 只有 `autorestart=true`），进行中的发送会被硬中断；无 `/health` 端点、无 gRPC health service（全模块 grep `health` 无匹配），聚合侧 `pkgs/all/internal/server/authorization.go:98` 虽把 `/grpc.health.` 设为匿名，但服务端从未注册健康服务；日志是 `fmt.Println` 纯文本，无级别/请求 ID/耗时/渠道/结果指标，线上无法定位「哪次发送失败」。README:375-392 宣称的健康检查/Prometheus/ELK/APM 均无实现。
- **建议**：注册信号处理 + `GracefulStop`（参考 `pkgs/all`），加 `grpc_health_v1` 与 HTTP `/healthz`，引入结构化日志与基础指标（发送量/成功率/各渠道耗时/验证码校验失败数），panic recovery 拦截器。
#### 24. 独立进程的 HTTP 网关从未注册业务 handler（`Mux` 恒为 nil）
- **位置**：`module/base/sender/internal/server/new.go:13-30`、`module/base/sender/cmd/main/main.go:29,40`、`module/base/sender/service/expose.go:22-36`
- **证据**：
```go
// server/new.go:26-30 —— Server.Mux 从未被赋值（同文件全文无 srv.Mux = ...）
srv := &Server{ Ctx: context.Background(), Grpc: grpcServ, grpcConns: make(map[string]*grpc.ClientConn) }
```
```go
// cmd/main/main.go:40 —— 把 nil 的 Mux 交给 SDK 网关
GatewayMux: s.Mux,
```
- **影响**：只有 `service.Expose()`（由 `pkgs/all` 调用，`pkgs/all/internal/service/sender.go:11-21`）才会 `pb.RegisterSmsHandlerServer(...)` 到 mux；`cmd/main` 独立启动路径既不注册 handler 也不创建 mux，SDK 侧 `http.ListenAndServe(addr, mux)` 拿到的是 nil `*runtime.ServeMux`，任何 HTTP 请求都会走到 nil 接收者解引用（`grpc-gateway/v2@v2.30.0/runtime/mux.go:418` 访问 `s.unescapingMode`）→ 请求级 panic/连接被断开，`README` 与 `test/http/*.http` 里那些 `api.apinb.com/sender.Sms/Send` 的 HTTP 用法在独立部署下不可用。
- **建议**：在 `server.New` 中初始化 `Mux: gwRuntime.NewServeMux()`，或在 `cmd/main` 中改为调用 `service.Expose(...)`（与 `pkgs/all` 一致）；补一个独立启动的冒烟测试。（注：同样的 `Mux` 未初始化模式在 `ads/cms/passport/...` 等多个模块的 `cmd/main` 中重复出现，属系统性模板缺陷。）
#### 25. 幂等性缺失：重复发送无去重，且无发送记录用于对账
- **位置**：`module/base/sender/internal/logic/sms/send.go:26-100`、`module/base/sender/internal/logic/mail/send.go:22-69`（全模块无 request_id/幂等键/发送流水表）
- **证据**：
```go
// sms/send.go:76-93 —— 无幂等键，同一请求重放即再发一条短信
switch strings.ToLower(in.GetProvider()) {
case "aliyun":
...
result, err = AliyunSender(in, smsCode)
```
```go
// mail/send.go:66-68 —— 成功只回 OK，不落任何发送记录
return &pb.SendMailReply{ Data: vars.OK }, nil
```
- **影响**：调用方超时重试、gRPC 重试、用户连点都会重复发送（短信按条计费）；发送结果不落库，问题 15（把失败当成功）发生后无法对账与补偿，也无法审计「谁在什么时候给哪个号码发了什么」。
- **建议**：引入调用方传入的 `request_id`（或对 `phone+template+分钟窗口` 做 Redis 幂等键），并对每次发送落一条流水（渠道/模板/收件方哈希/厂商 msg_id/状态/错误），作为对账与风控数据源。
#### 26. 邮件报文头不规范：无 `Content-Type`/字符集、`Subject`/`FromName` 未按 RFC 2047 编码、`Rcpt` 使用未归一化地址
- **位置**：`module/base/sender/internal/logic/mail/send.go:127-129`、`internal/logic/mail/send.go:111`
- **证据**：
```go
// mail/send.go:127-129 —— 手工拼接头部，无 Content-Type/charset、无 Date/Message-ID，中文主题不编码
mailBody := "From: " + cfg.FromName + "<" + cfg.FromAddress + ">\n"
mailBody += "To: " + to + "\n"
mailBody += "Subject: " + subject + "\n\n"
```
```go
// mail/send.go:111 —— 直接用未解析的原始串做信封收件人
err = client.Rcpt(to)
```
- **影响**：不含 `Content-Type: text/html; charset=UTF-8` 时，正文按 US-ASCII 解释，中文内容在多数客户端乱码；中文 `Subject`/`FromName`（README:102 示例就是「系统通知」）未做 RFC 2047 编码同样乱码，且 `FromName<addr>` 缺空格不符合 RFC 5322 语法，部分 MTA 会拒收；缺 `Date`/`Message-ID` 会提高被判垃圾邮件的概率。`Rcpt(to)` 使用原始输入而非 `mail.ParseAddress` 解析出的地址，形如 `"Name <a@b.com>"` 的合法输入会导致信封命令非法而投递失败。（说明：`to` 本身经 `mail.ParseAddress` 校验，CRLF 注入会被 `net/mail` 的「expected single address」检查拒绝，故此处不构成头部注入。）
- **建议**：改用 `mail.Address` + `mime.QEncoding`/`mime.WordEncoder` 生成头部，补 `Content-Type`（含 charset 与 `Content-Transfer-Encoding`）、`Date`、`Message-ID`；发送前用 `mail.ParseAddress` 的 `Address` 字段做 `Rcpt`。
#### 27. 邮件模板统一用 `html/template`，纯文本邮件会被 HTML 转义污染
- **位置**：`module/base/sender/internal/logic/mail/send.go:8,49`
- **证据**：
```go
import "html/template"
...
tmpl, err := template.New("page").Parse(tplRecord.Body)
```
- **影响**：`html/template` 会对参数做 HTML 实体转义（`&` → `&amp;`、`<` → `&lt;`）。当模板用于纯文本邮件（且报文头也没有声明 `text/html`）时，用户会看到 `&amp;` 之类的乱码内容；反过来若改用 `text/template` 则失去 HTML 转义保护。模板类型与转义策略没有建模。
- **建议**：为模板增加类型/内容类型字段，按类型选择 `html/template` 或 `text/template`，并把 `Content-Type` 与之一致；对 HTML 模板保留转义（当前 `html/template` 对参数转义是正确做法）。
#### 28. 渠道抽象缺失：`switch` 硬编码，README 的扩展指引与实现不符
- **位置**：`internal/logic/sms/send.go:76-89`、`internal/logic/mail/send.go:55-60`、`README.md:234-287`
- **证据**：
```go
// mail/send.go:55-60 —— QQ() 名为 QQ，实为通用 SMTP；新增渠道要改 switch
case "qq":
err = QQ(cfg, tmpl, in.GetTo(), tplRecord.Subjet, in.GetParamters())
default:
return nil, excode.ErrNotProvider
```
- **影响**：README:246-259 教开发者在 `send.go` 的 switch 里加分支并「实现新服务商的发送函数」，但没有任何接口（interface）/注册表抽象，渠道名与实现散落在 `switch`、`withProvider` 的 `switch`、yaml key 三处，容易漏改（本次 gmail/tencent 就是这么漏的）。SMS 侧同样如此（`sms/send.go:76-89`）。
- **建议**：定义 `SmsProvider` / `MailProvider` 接口与注册表（`map[string]Provider` + `Register(name, impl)`），配置驱动装配；README 的扩展指引同步改为「实现接口并注册」。
### P3
#### 29. 文档与实现严重不一致（README/UPGRADE_SUMMARY 描述了不存在的能力与文件）
- **位置**：`README.md:9,18,149-151,155,170,205-206,234-287,352,363-365,375-392`、`UPGRADE_SUMMARY.md:60-68`
- **证据**：
```markdown
README.md:149-150
- **gRPC服务**：`localhost:12201`
- **HTTP Gateway**：`localhost:12202`
```
实际端口是 12208/12207（`etc/sender_prod.yaml:2,23`）；README:155 写的 `POST /v1/sms/send`，实际路由是 `/sender.Sms/Send`（`pb/sms.pb.gw.go:216`、`pb/mail.pb.gw.go:152`）；README:363-365 说 `Code.MaxSentLimit` 默认 10，配置里是 5（`etc/sender_prod.yaml:46`）；README:205-206 的 `scripts/`、`swagger/` 目录不存在；README/Makefile/Dockerfile/docker-compose.yml/CHANGELOG.md 均不存在（`UPGRADE_SUMMARY.md:62-68` 却声称「新增文件」）；README:352/375-392 宣称的 `/health`、Prometheus、ELK、APM、覆盖率 >80% 都无实现（全模块无 health 注册、无指标导出、无 CI 配置）。
- **影响**：运维按文档配置端口/路径会直接失败；「新增文件」的虚假记录会误导后续维护者以为容器化/构建体系已就绪。
- **建议**：以实际实现为准重写 README（端口、路径、渠道、限额默认值、扩展步骤），删除或补齐 UPGRADE_SUMMARY 中声称的文件；补充可执行的 curl/`.http` 示例（`test/http/*.http` 目前指向 `api.apinb.com` 生产域名）。
#### 30. 命名拼写错误（对外协议字段与数据库字段）
- **位置**：`proto/sms.proto:18`、`proto/mail.proto:16`、`internal/models/sender_template.go:12`
- **证据**：
```protobuf
// proto/sms.proto:18
map<string,string> paramters=5; // 验证码相关
```
```go
// internal/models/sender_template.go:12
Subjet string `gorm:"type:varchar(255);not null;default:'';comment:邮件主题"`
```
`paramters`（应为 `parameters`）已固化进 protobuf 字段名与 JSON 名（`pb/sms.pb.go:32`），`Subjet`（应为 `Subject`）已固化进数据库列名；`impl.MemorySerice`（`internal/impl/impl.go:16`）同样拼错。
- **影响**：协议字段拼写错误一旦上线难以单方面修正（需兼容期双字段）；列名拼写错误在库里永久存在。
- **建议**：`Subjet` 与 `MemorySerice` 在本次无外部兼容负担时直接更正；`paramters` 通过新增 `parameters` 字段 + 双读兼容再下线旧字段，避免破坏现有调用方。
#### 31. 手机号校验正则过于宽松
- **位置**：`module/base/sender/internal/logic/sms/send.go:155-159`
- **证据**：
```go
result, _ := regexp.MatchString(`^(1[3|4|5|6|7|8|9][0-9]\d{4,8})$`, phone)
```
- **影响**：字符类 `[3|4|...]` 里含无意义的 `|`；`\d{4,8}` 允许总长 7–11 位（如 `1301234`），非法号码也能通过校验并真实提交到云厂商（每条都可能计费/失败计数），浪费额度与配额；不支持国际号码（`+86`/`00` 前缀）与 `PhoneNumbers` 多号码批量。
- **建议**：收紧为 `^1[3-9]\d{9}$`（必要时再单独支持 E.164 国际格式），并把号码规范化（去空格/`+86`）后再送厂商。
#### 32. 限流窗口使用进程本地时区
- **位置**：`module/base/sender/internal/logic/sms/send.go:42`、`internal/logic/sms/const.go:4`
- **证据**：
```go
// sms/send.go:42 + const.go:4 FormatDay = "2006-01-02"
limitKey := LimitCacheKey + time.Now().Format(FormatDay) + in.GetPhone()
```
- **影响**：日期分界取决于容器本地时区（生产镜像常为 UTC），与业务时区（`Asia/Shanghai`，见 DB DSN `etc/sender_prod.yaml:7`）不一致，会造成「凌晨 8 小时窗口重叠/提前重置」的计数错乱（在问题 2 修复后才会显现）。同理，`Code.Expire` 用 `time.Second * Expire` 尚可，但没有任何时间来源统一约定。
- **建议**：统一显式加载 `time.LoadLocation("Asia/Shanghai")` 并用 `time.Now().In(loc)`；或直接以滑动窗口（`INCR` + `EXPIRE 24h`）替代「自然日」键，避免时区语义。
#### 33. 模板参数无白名单/长度限制，且把云厂商原始响应回传调用方
- **位置**：`module/base/sender/internal/logic/sms/send.go:107-109`、`internal/logic/sms/send.go:95-99`
- **证据**：
```go
// sms/send.go:107-109 —— 任意 key/value 直接进入厂商模板参数
for key, val := range args.Paramters {
templateParam[key] = val
}
```
- **影响**：`TemplateParam` 的 key/value 完全不受控（可注入超长内容、任意占位符名），在 `is_gen_code=false` 场景下短信正文内容由调用方决定（问题 1/12 的放大面）；响应体直接回传厂商 JSON（`Reply: string(jsonBytes)`），对外暴露账号与模板信息。
- **建议**：对 `paramters` 做 key 白名单 + value 长度/字符集校验（并过滤换行等控制字符以符合短信规范）；响应只返回必要的 `msg_id`/状态。
#### 34. 部署配置：supervisor 以 root 运行、无日志轮转、无优雅停止
- **位置**：`etc/supervisor.bsm-apps-sender.conf:1-8`
- **证据**：
```ini
command=/data/app/bsm-apps-sender
user=root
redirect_stderr=true
stdout_logfile=/data/app/logs/apps-sender.log
```
- **影响**：以 root 运行放大了任何代码执行/文件写入类漏洞的后果；`stdout_logfile` 无 `stdout_logfile_maxbytes`/轮转配置，日志无限增长（配合问题 10 的明文验证码日志更严重）；无 `stopasgroup`/`killasgroup` 与优雅停止信号约定（见问题 23）。
- **建议**：改用非特权用户运行、配置日志轮转、显式声明 `stopsignal=TERM` 与优雅停止超时。
## 4. 推荐优化方案
按「先堵安全、再修正确性、后补可观测与工程化」推进：
1. **访问控制与配额（P0-1/2/16）**
- 模块内加鉴权拦截器（gRPC `UnaryInterceptor` + gateway middleware）：校验内部服务凭据或用户 JWT，并校验「手机号/邮箱是否属于该用户」；`MicroService.Anonymous` 与 `pkgs/all` 的 `Authorization.Anonymous` 中移除 sender 三个方法。
- 签名/模板白名单化：`sign_name`/`template_code`/`template_key` 由服务端按业务场景决定，`paramters` 走 key 白名单 + 长度校验。
- 配额与频控落地：`INCR` + `EXPIRE` 原子计数（手机号/日、手机号/小时、手机号/60s、账号/日、IP/日），超限返回明确错误码；配额在发送前占用、失败回滚。
2. **验证码安全（P0-3/4、P1-12）**
- `crypto/rand` 生成；`Set` 覆盖写并检查错误；`code` 参数服务端独占注入，禁止被 `paramters` 覆盖。
- 校验用 `GETDEL` 一次性消费；失败计数 + 锁定；失败不删 key；返回明确错误码而非 `"false"+nil`。
3. **外部调用健壮性（P1-5/7/8/9）**
- 短信：`CallApiWithCtx` + 显式 `ConnectTimeout/ReadTimeout` + 重试/熔断 + 渠道接口化（补齐或删除 tencent）。
- 邮件：`defer client.Close()+Quit()`、dial/会话超时、`mail.Address`/RFC 2047/MIME 头、失败路径判空、异步队列 + 退避重试。
- 全链路 `ctx` 贯穿（含 Redis：用请求 ctx 而不是 `impl.RedisService.Ctx`，并给 Redis 操作加超时）。
4. **配置与密钥（P1-10/13/14）**
- 启动期校验 `Code/SMS/SMTP`，`Endpoint` 白名单校验；口令/AK 全部外置（环境变量/配置中心）并轮换已入库凭据；日志脱敏 + 结构化；删除验证码明文打印。
5. **可观测与运维（P2-23/24/25、P3-34）**
- 信号处理 + `GracefulStop`、`grpc_health_v1` + `/healthz`、panic recovery、结构化日志（request_id/渠道/耗时/结果）、Prometheus 指标（发送量、成功率、各渠道延迟、验证码失败率）、发送流水表支持对账。
6. **工程化（P2-19/20/29、P3-29/30）**
- 迁移改为显式命令；模板缓存；补单元测试（`GenValidateCode`/`VerifyPhone`/`ValidateEmail`/模板渲染/限额与验证码状态机）+ 接口 mock；更正拼写；README 与实现对齐（端口、路径、渠道、默认限额）。
## 5. TODO 清单
- [ ] **P0-1** 给 `Sms.Send/Verify`、`Mail.Send` 加身份与归属校验，并从两份 `Anonymous` 列表移除这三个方法｜验收：未带凭据调用返回鉴权错误；带 A 用户凭据给非 A 的手机号/邮箱发送被拒绝｜涉及：`module/base/sender/internal/logic/sms/send.go:26`、`module/base/sender/internal/logic/mail/send.go:22`、`module/base/sender/etc/sender_prod.yaml:15`、`pkgs/all/etc/default_dev.yaml:24`
- [ ] **P0-2** 用 `INCR`+`EXPIRE` 实现手机号日/时/分钟配额与账号/IP 频控，配额先占后退｜验收：单测覆盖第 6 次发送被拒、计数键有 TTL、发送失败后计数回滚｜涉及：`module/base/sender/internal/logic/sms/send.go:41`
- [ ] **P0-2b** 邮件侧补齐发送配额与频控、收件人策略｜验收：同收件人 60s 内二次发送被拒；日配额生效｜涉及：`module/base/sender/internal/logic/mail/send.go:22`
- [ ] **P0-3** `Verify` 改为 `GETDEL` 一次性消费，新增失败计数与锁定，失败分支不删 key｜验收：正确验证码二次校验失败；连续 5 次错误后验证码失效并锁定；错误码非 nil｜涉及：`module/base/sender/internal/logic/sms/verify.go:28`
- [ ] **P0-4** 验证码改用 `crypto/rand`｜验收：单测统计 10 万次生成分布无重复模式，代码中不存在 `math/rand`｜涉及：`module/base/sender/internal/logic/sms/send.go:162`
- [ ] **P1-5** 实现腾讯云 `SendSms` 或删除 `tencent` 分支并同步文档，禁止 `(nil,nil)` 假成功｜验收：`provider=tencent` 要么真实下发并返回 msg_id，要么返回 `ErrNotProvider`｜涉及：`module/base/sender/internal/logic/sms/send.go:151`
- [ ] **P1-6** 邮件渠道改为按 `provider` 直取配置（去掉 `switch`），并实现或删除 `is_gen_code`｜验收：新增渠道只需加配置；`is_gen_code=true` 时验证码落 Redis 且可校验（或有明确返回）｜涉及：`module/base/sender/internal/logic/mail/send.go:55`、`module/base/sender/proto/mail.proto:15`
- [ ] **P1-7** 短信调用改 `CallApiWithCtx` 并设置 Connect/Read 超时与重试｜验收：代码中无 `&dara.RuntimeOptions{}` 空结构；单测用假 endpoint 验证 5s 内返回超时错误｜涉及：`module/base/sender/internal/logic/sms/send.go:123`
- [ ] **P1-8** 修复 SMTP 连接泄漏、加 dial/会话超时、增加异步队列与重试｜验收：连续发 1000 封后 `netstat` 无 ESTABLISHED 残留；SMTP 挂起时 10s 内返回错误｜涉及：`module/base/sender/internal/logic/mail/send.go:76`
- [ ] **P1-9** 修掉 `client.Close()` nil panic 并加 gRPC recovery 拦截器｜验收：SMTP greeting 失败时返回错误且进程不退出｜涉及：`module/base/sender/internal/logic/mail/send.go:89`、`module/base/sender/internal/server/new.go:23`
- [ ] **P1-10** 清理敏感日志（验证码/模板参数/DSN 口令）并改结构化日志｜验收：grep 日志输出无验证码、无 `password=`、无 AK/SK；启动日志口令为掩码｜涉及：`module/base/sender/internal/logic/sms/send.go:96`、`module/base/sender/internal/impl/impl.go:26`
- [ ] **P1-11** 黑名单机制落地：配置/管理入口写入 Redis set，检查失败按 fail-closed 处理｜验收：把号码加入黑名单后发送返回 `ErrInBlackList`；Redis 故障时拒绝发送并告警｜涉及：`module/base/sender/internal/logic/sms/send.go:37`、`module/base/sender/internal/config/config.go:55`
- [ ] **P1-12** 验证码写入改 `Set` 并检查错误；`code` 由服务端独占注入，禁止被 `paramters` 覆盖｜验收：300s 内二次发送后 Redis 中的码与用户收到的码一致；`paramters.code` 无法覆盖｜涉及：`module/base/sender/internal/logic/sms/send.go:65`
- [ ] **P1-13** 启动期校验 `Code/SMS/SMTP` 并给边界默认值，Redis/DB 客户端判空 fail-fast｜验收：缺失 `Code` 段时启动报明确错误而非请求期 panic｜涉及：`module/base/sender/internal/config/config.go:70`
- [ ] **P1-14** 修正 prod/test 配置（Endpoint、真实 DB/Redis、密钥外置）｜验收：prod 配置通过启动校验并能真实下发一条短信｜涉及：`module/base/sender/etc/sender_prod.yaml:38`
- [ ] **P1-15** 统一返回语义：失败返回非 nil error，Send 解析并映射厂商结果｜验收：错误验证码返回错误码；业务失败不被当成成功｜涉及：`module/base/sender/internal/logic/sms/verify.go:37`
- [ ] **P2-17** Provider 初始化失败降级而非 panic｜验收：单一渠道凭据错误时服务仍可启动，其他渠道可用｜涉及：`module/base/sender/internal/impl/provider.go:63`
- [ ] **P2-18** 去掉请求路径中的全局配置写入｜验收：`go test -race` 无告警｜涉及：`module/base/sender/internal/logic/sms/send.go:57`
- [ ] **P2-19** 迁移改为显式命令并补建表脚本/文档｜验收：新环境按文档建表后邮件发送成功；不再依赖请求期隐式建表｜涉及：`module/base/sender/internal/models/sender_template.go:16`
- [ ] **P2-20** 模板加缓存、SMTP 连接复用｜验收：模板命中缓存时无 DB 查询；连接数有上限｜涉及：`module/base/sender/internal/logic/mail/send.go:43`
- [ ] **P2-21** 清理死代码（`NewSMTP`/`Google`/`QQ`/`grpcConns`/`MemorySerice`/未用配置与错误码）｜验收：`go vet` 干净且无未引用导出符号｜涉及：`module/base/sender/internal/impl/provider.go:52`
- [ ] **P2-22** 补齐错误处理（`json.Marshal`/`regexp`/Redis 错误/DB 错误映射/双重 Close）｜验收：基础设施故障返回 5xx 类错误而非 1404 或假成功｜涉及：`module/base/sender/internal/logic/mail/send.go:43`
- [ ] **P2-23** 加信号处理+GracefulStop、health 端点、panic recovery、结构化日志与指标｜验收：TERM 后 10s 内退出且无中断中的发送；`/healthz` 200｜涉及：`module/base/sender/cmd/main/main.go:45`
- [ ] **P2-24** 初始化 `Server.Mux` 或让独立入口走 `service.Expose`｜验收：独立启动后 `POST /sender.Sms/Verify` 返回业务错误而非 panic/断连｜涉及：`module/base/sender/internal/server/new.go:26`
- [ ] **P2-25** 引入幂等键与发送流水表｜验收：同 `request_id` 重放不产生第二条短信；可按 request_id 查询发送结果｜涉及：`module/base/sender/internal/logic/sms/send.go:76`
- [ ] **P2-26** 邮件头规范化（MIME/charset/RFC2047/Date/Message-ID，`Rcpt` 用解析后地址）｜验收：中文主题与正文在 QQ/Gmail 客户端显示正常；`"Name <a@b.com>"` 输入可正常投递｜涉及：`module/base/sender/internal/logic/mail/send.go:127`
- [ ] **P2-28** 渠道接口化 + 注册表，README 扩展指引同步｜验收：新增渠道不改 `switch`，仅新增实现并注册｜涉及：`module/base/sender/internal/logic/mail/send.go:55`
- [ ] **P3-29** README/UPGRADE_SUMMARY 与实现对齐｜验收：文档中的端口、路径、渠道、默认限额、文件清单逐条可验证｜涉及：`README.md:150`、`UPGRADE_SUMMARY.md:62`
- [ ] **P3-31** 收紧手机号正则并做号码规范化｜验收：`1301234` 被拒，`+86 138...` 可正常发送｜涉及：`module/base/sender/internal/logic/sms/send.go:156`
- [ ] **P3-32** 限流窗口时区显式化｜验收：跨时区部署下计数窗口按 `Asia/Shanghai` 重置｜涉及：`module/base/sender/internal/logic/sms/send.go:42`
- [ ] **P3-34** supervisor 改非 root + 日志轮转｜验收：进程非 root 运行，日志按大小轮转｜涉及：`module/base/sender/etc/supervisor.bsm-apps-sender.conf:6`
## 6. 审计摘要（供汇总使用）
- 问题数：P0=4 P1=12 P2=12 P3=6（合计 34）
- 最高风险（一句话）：短信/邮件发送接口无鉴权且日限额计数器从未写入、验证码可无限次爆破并可被他人一条错误请求删除，任何能访问该服务（或任意注册用户）的人都可对任意手机号无限发送平台签名短信，直接造成短信轰炸、费用损失与钓鱼风险。
- 最优先 3 个动作：
1. 给 `Sms.Send/Verify`、`Mail.Send` 加身份+归属校验并从 `Anonymous` 列表移除，同时把「签名/模板/参数」改为服务端白名单。
2. 用 `INCR`+`EXPIRE` 真正落地手机号/账号/IP 配额与频控（当前 `LimitCacheKey` 只有读、没有写）。
3. 重写验证码生命周期：`crypto/rand` 生成、`Set` 覆盖并检查错误、`GETDEL` 一次性消费、失败计数与锁定、失败不删 key，并为验证码/口令做日志脱敏。
- 未能覆盖/无法验证的部分：
1. 未实跑服务：本机无 Redis/PostgreSQL/短信账号，全部结论来自静态阅读；`gofmt -l .` 与 `go vet ./...` 均无输出（exit 0），未执行 `-tags integration` 的集成测试（其指向真实 IP/域名并会发真实短信邮件）。
2. `api.apinb.com` 网关（etcd 匿名列表的实际消费方）不在本工作区，「Anonymous 生效后即无鉴权放行」为**推测**；已在报告中标注。
3. 腾讯云 SMS 空实现的实际影响范围取决于部署是否真的配置了 `SMS.tencent`（仓库内三份 yaml 均未配置，仅代码路径存在）。
4. 阿里云超时结论基于本机 module cache 中 `darabonba-openapi/v2@v2.1.12` 与 `tea@v1.5.3` 的实现链（`Default(0,0)` → `httpClient.Timeout=0`）；若线上实际拉取的 SDK 版本不同，超时默认值可能不同。
5. 未做动态内存/fd 泄漏与压测验证（SMTP 连接泄漏、goroutine 堆积为静态推断）。
6. `pb/const.pb.go` 中大量与本模块无关的共享消息（market/order/cms 等）仅做存在性核对，未逐字段审计。
Reference in New Issue View Git Blame Copy Permalink