fix(ssrf-safety): restore SSRF safety checks and enhance diagnostics …#1833
Conversation
…for URL validation
📝 WalkthroughWalkthroughThe PR upgrades SSRF (Server-Side Request Forgery) protection by refactoring the DNS guard logic to filter resolved IPs and reject only when none are allowed, extends the forbidden hosts blocklist with additional CIDR ranges, validates both single and multi-address behaviors in tests, and integrates the guard into HTTP table actions with Slack diagnostics on failure. ChangesSSRF Protection Enhancement
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR restores and strengthens SSRF protections around outbound HTTP requests by improving DNS resolution handling, expanding the set of forbidden IP ranges, re-enabling SSRF-safe Axios configuration for table actions, and adding/expanding unit test coverage for the SSRF guard behavior.
Changes:
- Updated
ssrfGuardLookupto filter out forbidden DNS results (instead of rejecting hosts with any forbidden record) and to supportall=trueso Node can fall back across allowed addresses. - Expanded forbidden network ranges (CGNAT, benchmarking, IETF protocol assignments, and IPv6 unspecified address) and updated unit tests accordingly.
- Re-enabled SSRF-safe request configuration for table action HTTP activations and added temporary Slack diagnostics for SSRF guard rejections.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| backend/test/ava-tests/unit-tests/ssrf-safe-http.test.ts | Adds coverage for additional forbidden ranges and all=true behavior (including the “all resolved addresses forbidden” case). |
| backend/src/helpers/validators/ssrf-safe-http.ts | Filters forbidden DNS answers, returns all allowed answers when requested, and improves failure messaging when no allowed addresses remain. |
| backend/src/helpers/constants/constants.ts | Expands FORBIDDEN_HOSTS with additional special-purpose/non-routable ranges and ::/128. |
| backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts | Re-enables SSRF-safe Axios config for action webhooks and adds temporary Slack diagnostics for SSRF guard blocks. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const host = (() => { | ||
| try { | ||
| return new URL(tableAction.url).host; | ||
| } catch { | ||
| return tableAction.url; | ||
| } | ||
| })(); |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts (1)
230-245: 💤 Low valueVariable shadowing reduces readability.
errorMessageis declared at line 230 for the SSRF check, then again at line 245 inside the Axios error block. While this works correctly, the shadowing can cause confusion during maintenance.Consider renaming the first one:
♻️ Suggested rename
- const errorMessage = error instanceof Error ? error.message : String(error); - if (errorMessage.includes('SSRF guard')) { + const errorText = error instanceof Error ? error.message : String(error); + if (errorText.includes('SSRF guard')) {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts` around lines 230 - 245, The code shadows the variable errorMessage (declared before the SSRF check and re-declared inside the axios error branch), which reduces readability; rename one of them (e.g., rename the first errorMessage used for the SSRF guard to ssrfErrorMessage or rename the axios block's errorMessage to axiosErrorMessage) and update its usages (the SSRF host construction and slackPostMessage call or the axios.isAxiosError branch) so there is a single clear, non-shadowing identifier per scope (refer to error handling around the SSRF check, slackPostMessage, axios.isAxiosError, and tableAction.url).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In
`@backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts`:
- Around line 230-245: The code shadows the variable errorMessage (declared
before the SSRF check and re-declared inside the axios error branch), which
reduces readability; rename one of them (e.g., rename the first errorMessage
used for the SSRF guard to ssrfErrorMessage or rename the axios block's
errorMessage to axiosErrorMessage) and update its usages (the SSRF host
construction and slackPostMessage call or the axios.isAxiosError branch) so
there is a single clear, non-shadowing identifier per scope (refer to error
handling around the SSRF check, slackPostMessage, axios.isAxiosError, and
tableAction.url).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6f04e933-f797-4f62-b80c-a5f90b5f2220
📒 Files selected for processing (4)
backend/src/entities/table-actions/table-actions-module/table-action-activation.service.tsbackend/src/helpers/constants/constants.tsbackend/src/helpers/validators/ssrf-safe-http.tsbackend/test/ava-tests/unit-tests/ssrf-safe-http.test.ts
…for URL validation
Summary by CodeRabbit
Bug Fixes
Tests