fix(policy): block POST to sentry.io to prevent multi-tenant data exfiltration (#1437)#1623
fix(policy): block POST to sentry.io to prevent multi-tenant data exfiltration (#1437)#1623
Conversation
…iltration sentry.io is a multi-tenant SaaS — any client with a project ID can POST to any Sentry project, not just NemoClaw's. The baseline sandbox policy allowed POST to sentry.io with path '/**', which turned the host into a generic exfiltration channel: a compromised agent inside the sandbox could ship stack traces, env vars, file contents, etc. to a Sentry project controlled by an attacker via the public envelope endpoint (https://sentry.io/api/<any-project-id>/envelope/). Path-pattern restrictions cannot fix this because the project ID is part of the URL and there is no server-side allowlist of legitimate projects. This is a follow-up to #1214 (which added 'protocol: rest' for sentry.io) — that PR closed the wire-protocol gap, this PR closes the remaining HTTP-method-level gap. Changes: - nemoclaw-blueprint/policies/openclaw-sandbox.yaml: drop the 'method: POST, path: /**' allow rule for sentry.io. GET stays allowed because GET has no request body and is harmless for exfil. Side effect: Claude Code's crash telemetry to Sentry is silently dropped. That is the correct tradeoff for a sandbox whose stated goal is preventing data egress, and the sandbox already blocks many similar telemetry channels by default. - test/validate-blueprint.test.ts: walk every endpoint in network_policies, find sentry.io, and assert (a) at least one sentry.io entry exists, (b) no sentry.io entry has a POST allow rule, (c) the GET allow rule is preserved. Verified by stashing the policy fix and re-running: the test correctly fails on main with the unfixed policy, and passes with the fix in place. Closes #1437
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…1437) The path-scoped POST rules (/api/*/envelope/** and /api/*/store/**) do not prevent multi-tenant exfiltration because the Sentry project ID is part of the URL and attacker-controlled. Remove POST entirely so the endpoint is connection-only with no allowed methods. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
GET has no request body and is bounded by URL length limits, making it harmless for bulk exfiltration. Keeping it allows read-only Sentry SDK code paths (e.g. fetching public DSN config) to continue working. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe sandbox network policy for sentry.io is modified to restrict outbound traffic. POST requests to specific Sentry endpoints are removed, while GET access remains. This eliminates a data exfiltration vector where error reports could be sent to attacker-controlled Sentry projects. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Reverting to #1565 — the contributor's PR should stay open so a maintainer can review it. |
Summary
Closes #1437. Supersedes #1565.
/api/*/envelope/**and/api/*/store/**) from thesentry.ioendpoint in the sandbox network policyGET /**for read-only Sentry SDK paths (DSN config fetching) — GET has no request body and is bounded by URL length limits, making it harmless for bulk exfiltrationCredit to @ColinM-sys for the original analysis and fix in #1565.
Test plan
sentry.ioendpoint innemoclaw-blueprint/policies/openclaw-sandbox.yamlhas only a GET rule, no POSTnpm testto confirm no test regressions🤖 Generated with Claude Code
Summary by CodeRabbit