mirror of
https://github.com/screentinker/screentinker.git
synced 2026-05-15 07:32:23 -06:00
45a6800621
Express's req.ip was resolving to a Cloudflare edge address (e.g. 172.70.x.x) for any request fronted by Cloudflare, because trust proxy was set to '1' — that trusts the immediate hop, which IS Cloudflare. All activity_log rows from API paths captured the proxy, not the client. The WebSocket path was unaffected and recorded the real IP. Two layers of defense: 1. trust proxy now lists Cloudflare's published v4 + v6 ranges plus loopback / linklocal / uniquelocal (config/cloudflareIps.js). With this list req.ip resolves to the original client when fronted by CF, and X-Forwarded-For from any non-trusted source is ignored — so the value can't be spoofed. 2. New getClientIp(req) helper in services/activity.js prefers the CF-Connecting-IP header but only honors it when the immediate TCP peer is itself a trusted address. Same gate as trust proxy, so a visitor who hits the origin directly with a forged header is logged at their real address. Routed all five activity-log call sites (auth login success/failure, admin password reset, generic activityLogger middleware, and the in-memory rate-limiter key) through the helper. Logging-only change. No schema changes. Existing rows are not modified — fix applies to new entries going forward. Verified locally: - Bare loopback hit logs 127.0.0.1 (not a proxy address). - Helper unit cases including an untrusted peer (203.0.113.7) sending a forged CF-Connecting-IP correctly fall back to the real peer. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| cloudflareIps.js | ||