fix(table-action-activation): temporarily disable SSRF/URL safety check in activateTableAction#1830
Conversation
…ck in activateTableAction
📝 WalkthroughWalkthroughA single HTTP table action service file temporarily disables SSRF/URL safety validation by commenting out the ChangesSSRF safety check temporary disable
🎯 2 (Simple) | ⏱️ ~5 minutes
🚥 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 temporarily disables the SSRF/URL safety protections applied to URL-based table actions (activateHttpTableAction) by removing getSsrfSafeRequestConfig() from the Axios request configuration.
Changes:
- Commented out the
getSsrfSafeRequestConfigimport. - Removed the SSRF-safe Axios request config from the
axios.post(...)call and added an explicit 10s timeout.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // TODO: temporarily disabled SSRF/URL safety check in activateTableAction. Restore import to re-enable. | ||
| // import { getSsrfSafeRequestConfig } from '../../../helpers/validators/ssrf-safe-http.js'; |
| // TODO: SSRF/URL safety check temporarily disabled. Restore the line below to re-enable. | ||
| // ...getSsrfSafeRequestConfig(), | ||
| timeout: 10_000, |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts (1)
121-121:⚠️ Potential issue | 🟠 Major | ⚡ Quick winInconsistent SSRF protection: Slack actions are protected but HTTP actions are not.
actionSlackPostMessage(context snippet 3) still appliesgetSsrfSafeRequestConfig(), meaning Slack webhooks have SSRF protection while HTTP table actions do not. This creates an inconsistent security posture where the same service treats similar outbound requests differently.If SSRF protection must be disabled for HTTP actions due to a specific technical issue, the same reasoning may apply to Slack actions—or vice versa. Ensure the protection strategy is consistent across all outbound request types.
🤖 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` at line 121, The code applies SSRF protection via getSsrfSafeRequestConfig() for Slack webhook calls (actionSlackPostMessage) but not for HTTP table actions, causing inconsistent protection; update the HTTP table action request path (where outbound HTTP table actions are executed) to use the same getSsrfSafeRequestConfig() wrapper or, if you decide SSRF protection must be disabled for all outbound actions, remove the SSRF usage from actionSlackPostMessage so both paths are consistent; identify and change the HTTP action request function and actionSlackPostMessage call sites to share a single helper (e.g., use getSsrfSafeRequestConfig() uniformly) and add a short comment explaining the chosen global SSRF policy.
🤖 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.
Inline comments:
In
`@backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts`:
- Around line 16-17: The SSRF protection was disabled by removing the
getSsrfSafeRequestConfig import used by activateTableAction; restore SSRF
defenses by re-importing getSsrfSafeRequestConfig and passing its returned
httpAgent/httpsAgent into the HTTP request config used in activateTableAction
(and the related call sites around lines 215-217), so requests are blocked to
private IP ranges; if temporarily unavoidable, add an explicit allowlist check
against tableAction.url and add a TODO linking a tracking issue and deadline
before leaving the helper disabled.
---
Outside diff comments:
In
`@backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts`:
- Line 121: The code applies SSRF protection via getSsrfSafeRequestConfig() for
Slack webhook calls (actionSlackPostMessage) but not for HTTP table actions,
causing inconsistent protection; update the HTTP table action request path
(where outbound HTTP table actions are executed) to use the same
getSsrfSafeRequestConfig() wrapper or, if you decide SSRF protection must be
disabled for all outbound actions, remove the SSRF usage from
actionSlackPostMessage so both paths are consistent; identify and change the
HTTP action request function and actionSlackPostMessage call sites to share a
single helper (e.g., use getSsrfSafeRequestConfig() uniformly) and add a short
comment explaining the chosen global SSRF policy.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b12ef6d4-acd0-4723-840d-3257b65e0ce3
📒 Files selected for processing (1)
backend/src/entities/table-actions/table-actions-module/table-action-activation.service.ts
| // TODO: temporarily disabled SSRF/URL safety check in activateTableAction. Restore import to re-enable. | ||
| // import { getSsrfSafeRequestConfig } from '../../../helpers/validators/ssrf-safe-http.js'; |
There was a problem hiding this comment.
Critical: Disabling SSRF protection enables attacks on internal infrastructure in SaaS mode.
The getSsrfSafeRequestConfig() helper provides httpAgent/httpsAgent with DNS lookup guards that block requests to private IPs (127.0.0.1, 10.x.x.x, 192.168.x.x, 169.254.169.254, etc.). Without this protection, a malicious user in SaaS mode can configure a table action URL targeting:
- Internal services (e.g.,
http://localhost:8080/admin) - Cloud metadata endpoints (e.g.,
http://169.254.169.254/latest/meta-data/iam/security-credentials/) - Private network resources
While timeout and maxRedirects: 0 are preserved, they don't prevent the core SSRF threat—the IP-based filtering is what blocks internal requests.
If this must be disabled temporarily due to a blocking issue, consider:
- Adding an allowlist check for
tableAction.urlagainst known-safe patterns - Documenting the specific issue requiring this workaround in the TODO
- Creating a tracking issue with a deadline for re-enabling
Also applies to: 215-217
🤖 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 16 - 17, The SSRF protection was disabled by removing the
getSsrfSafeRequestConfig import used by activateTableAction; restore SSRF
defenses by re-importing getSsrfSafeRequestConfig and passing its returned
httpAgent/httpsAgent into the HTTP request config used in activateTableAction
(and the related call sites around lines 215-217), so requests are blocked to
private IP ranges; if temporarily unavoidable, add an explicit allowlist check
against tableAction.url and add a TODO linking a tracking issue and deadline
before leaving the helper disabled.
Summary by CodeRabbit