2 Commits

Include renames

Author	SHA1	Message	Date
3 people	78228e68dd	security: throttle every credential-guessing endpoint, fix duplicate Rack::Attack middleware (#3263) ... * security: throttle every credential-guessing endpoint, fix duplicate Rack::Attack middleware Follow-up on #1087 (Findings H4, M7). PR 4 of the 6-PR series. Enumerated every endpoint that checks a password, TOTP code, or backup code (grepped for User.authenticate_by/#authenticate/#verify_otp? across app/controllers, not just the ones named in the issue) — six in total, none previously throttled: - POST /sessions (SessionsController#create) — web login - POST /mfa/verify (MfaController#verify_code) — TOTP + backup codes (#verify_otp? handles both internally, so no separate endpoint to add) - POST /password_reset (PasswordResetsController#create) — also M7 - POST /api/v1/auth/login (Api::V1::AuthController#login) — mobile/API - POST /oidc_account/create_link (OidcAccountsController#create_link) — password check gating SSO-identity linking, not sign-in; easy to miss grepping routes.rb for "session"/"login" - POST /api/v1/auth/sso_link (Api::V1::AuthController#sso_link) — same as above for the mobile app Each gets two throttles (ip AND normalized email, or ip AND the MFA step-up's session-bound user id where there's no email param) so an attacker can't bypass by rotating IPs against one target, nor by spraying many emails from one IP — Rack::Attack requires every matching throttle to pass. limit: 10/minute, matching the existing oauth/token and admin/ip throttles already in this file. Also fixed a latent, unrelated-but-adjacent bug found while confirming these throttles would actually enforce the limits documented in their own comments: config/application.rb had an explicit `config.middleware.use Rack::Attack` alongside the gem's own Railtie doing the same thing (`bin/rails middleware` listed it twice) — every throttle's counter was incrementing twice per request, so all of them, old and new, were silently firing at half their documented limit. Removed the redundant explicit registration. Race-condition check (per standing instruction): Rack::Attack's counter increments are atomic within its cache store, so concurrent requests at the threshold don't undercount. No new race introduced. New tests in test/integration/rack_attack_test.rb: - Registration checks for all 6 new throttle keys (existing convention in this file). - Direct block-level tests for the discriminator logic (right path matched, right value extracted, blank/missing input produces nil rather than a bogus key) — Rack::Attack's cache backs onto Rails.cache, which is :null_store in the test environment, so no amount of request volume in a normal integration test can ever actually trip a throttle here; calling the registered block directly against a constructed Rack::Attack::Request is what makes the assertions meaningful instead of just checking string keys exist. - Regression test asserting Rack::Attack appears exactly once in the middleware stack. Verified against the NAS sure_test_web container: full restart, bin/rails test (8/8 rack_attack tests green; ran the full test/integration suite plus sessions/mfa/password_resets/api-auth/oidc_accounts controller tests too — 6 pre-existing failures, confirmed identical on the unmodified baseline before concluding they're the known WebAuthn-RP-ID-mismatch and AI-disabled environmental categories, not a regression), bin/rubocop, bin/brakeman. Also did a live demonstration against the running container (which runs RAILS_ENV=production, where Rack::Attack is actually enabled): 12 rapid POSTs to /sessions with bad credentials — requests 1-10 got 422, 11 and 12 got 429, exactly matching limit: 10. Container restored to its original state and restarted afterward. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * security: extract email from JSON bodies for credential-guess throttles Rack::Attack runs before Rails' JSON parameter parsing, so request.params only exposed query/form fields. The documented api/v1/auth/login and .../sso_link JSON format bypassed the per-email throttle entirely, letting an attacker rotate IPs against one target's account. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * security: guard JSON email peek against non-rewindable input and non-object payloads Rack 3 no longer requires rack.input to be rewindable, and a bare JSON.parse(body)["email"] raises NoMethodError on valid non-Hash JSON (null, arrays, scalars) — either would 500 the request instead of just skipping the email throttle. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * security: assert non-rewindable JSON bodies stay readable by the controller Only checking that the throttle discriminator returned nil left a gap: an implementation that read the body and then discarded the result on error would pass the same assertion while leaving the controller with an exhausted stream. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * security: close credential-guessing throttle bypass via format-suffixed paths request.path == "/sessions" (etc.) never matched "/sessions.json", which Rails still routes to the same controller action since none of these routes are declared format: false. Match the optional format suffix explicitly instead, per jjmata's review on PR #3263. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * security: match Rails' actual format-segment charset in credential_guess_path \w excludes hyphens, but Rails' default (.:format) segment matches [^./?]+, which does include them — e.g. "/api/v1/auth/login.rate-limit" still routed and bypassed the throttle. Match the real charset instead, per CodeRabbit's follow-up on PR #3263. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Gerald <248542187+gfr-free@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 07:48:58 +02:00
Josh PigfordandClaude	b803ddac96	Add comprehensive API v1 with OAuth and API key authentication (#2389) ... * OAuth * Add API test routes and update Doorkeeper token handling for test environment - Introduced API namespace with test routes for controller testing in the test environment. - Updated Doorkeeper configuration to allow fallback to plain tokens in the test environment for easier testing. - Modified schema to change resource_owner_id type from bigint to string. * Implement API key authentication and enhance access control - Replaced Doorkeeper OAuth authentication with a custom method supporting both OAuth and API keys in the BaseController. - Added methods for API key authentication, including validation and logging. - Introduced scope-based authorization for API keys in the TestController. - Updated routes to include API key management endpoints. - Enhanced logging for API access to include authentication method details. - Added tests for API key functionality, including validation, scope checks, and access control enforcement. * Add API key rate limiting and usage tracking - Implemented rate limiting for API key authentication in BaseController. - Added methods to check rate limits, render appropriate responses, and include rate limit headers in responses. - Updated routes to include a new usage resource for tracking API usage. - Enhanced tests to verify rate limit functionality, including exceeding limits and per-key tracking. - Cleaned up Redis data in tests to ensure isolation between test cases. * Add Jbuilder for JSON rendering and refactor AccountsController - Added Jbuilder gem for improved JSON response handling. - Refactored index action in AccountsController to utilize Jbuilder for rendering JSON. - Removed manual serialization of accounts and streamlined response structure. - Implemented a before_action in BaseController to enforce JSON format for all API requests. * Add transactions resource to API routes - Added routes for transactions, allowing index, show, create, update, and destroy actions. - This enhancement supports comprehensive transaction management within the API. * Enhance API authentication and onboarding handling - Updated BaseController to skip onboarding requirements for API endpoints and added manual token verification for OAuth authentication. - Improved error handling and logging for invalid access tokens. - Introduced a method to set up the current context for API requests, ensuring compatibility with session-like behavior. - Excluded API paths from onboarding redirects in the Onboardable concern. - Updated database schema to change resource_owner_id type from bigint to string for OAuth access grants. * Fix rubocop offenses - Fix indentation and spacing issues - Convert single quotes to double quotes - Add spaces inside array brackets - Fix comment alignment - Add missing trailing newlines - Correct else/end alignment 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * Fix API test failures and improve test reliability - Fix ApiRateLimiterTest by removing mock users method and using fixtures - Fix UsageControllerTest by removing mock users method and using fixtures - Fix BaseControllerTest by using different users for multiple API keys - Use unique display_key values with SecureRandom to avoid conflicts - Fix double render issue in UsageController by returning after authorize_scope\! - Specify controller name in routes for usage resource - Remove trailing whitespace and empty lines per Rubocop All tests now pass and linting is clean. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * Add API transactions controller warning to brakeman ignore The account_id parameter in the API transactions controller is properly validated on line 79: family.accounts.find(transaction_params[:account_id]) This ensures users can only create transactions in accounts belonging to their family, making this a false positive. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> --------- Signed-off-by: Josh Pigford <josh@joshpigford.com> Co-authored-by: Claude <noreply@anthropic.com>	2025-06-17 15:57:05 -05:00