rails engine before_action: Get context from rack env - #358
Conversation
Summary by Aikido
🐛 Bugfixes
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
| # Read from the Rack env, not the fiber-local current_context: that one is nil when the | ||
| # action runs in another thread (ActionController::Live) or when no middleware ran at | ||
| # all (ActionController::TestCase). See https://github.com/AikidoSec/firewall-ruby/issues/357 | ||
| before_action { request.env[Aikido::Zen::ENV_KEY]&.update_request(request) } |
There was a problem hiding this comment.
🟠 High - ActionController::Live requests run outside Zen's request context
The new before_action stops dereferencing a nil context in ActionController::Live by reading from request.env, but it never rebinds that env-backed context to Aikido::Zen.current_context in the controller thread. All request-scoped protections still consume current_context (enable_idor_protection, track_user, set_tenant_id, and Sink#scan), and several scanners explicitly skip when it is nil, so streaming actions now become reachable while SQLi/SSRF/path traversal/shell checks, user-based blocking, and IDOR protection silently stop applying. This change therefore converts Live endpoints from a hard failure into an unprotected execution path.
Show fix
When controller callbacks/actions run, copy request.env[Aikido::Zen::ENV_KEY] into Aikido::Zen.current_context for the duration of that execution and restore the previous value afterward. That rebinding needs to happen before calling enable_idor_protection/update_request so controller-thread helpers and all sink scanners observe the same request context; add a regression test with an ActionController::Live action that calls track_user or set_tenant_id and exercises a protected sink.
Reply to ignore this finding.
More info
1 participant
for: #357