Skip to content

Conversation

lancejames221b
Copy link

Security Fix: CSRF Protection Bypass

Vulnerability Summary

MEDIUM SEVERITY - Fixes CSRF protection bypass that could allow cross-site request forgery attacks when password authentication is enabled.

CVSS Score

Medium (6.1) - Cross-Site Request Forgery

Vulnerability Details

  • Location: apps/routerconsole/java/src/net/i2p/router/web/FormHandler.java
  • Issue: CSRF protection could be bypassed when password authentication was enabled
  • Impact: Unauthorized actions could be performed via CSRF attacks

Changes Made

  • Removed dangerous CSRF bypass when password authentication is enabled
  • Implemented multi-layer CSRF token validation with enhanced security
  • Added constant-time string comparison to prevent timing attacks on tokens
  • Enhanced nonce generation with more secure 256-bit token creation
  • Maintained backward compatibility while strengthening protection

Security Improvements

  • Always validates CSRF tokens regardless of password settings
  • Prevents timing attacks on CSRF token validation
  • Enhanced token generation for stronger entropy
  • Multiple validation layers for comprehensive protection
  • Session-specific token framework for future improvements

Technical Details

  • Multi-layer validation: Session tokens, shared nonce, stored session nonces
  • Timing attack protection: Constant-time string comparison
  • Enhanced token generation: 4x long concatenation for 256-bit tokens
  • Backward compatibility: Maintains existing token validation paths
  • Future-ready: Framework for session-specific tokens

Testing

  • Full compilation testing completed successfully
  • CSRF protection logic verified
  • Token validation tested across scenarios
  • Backward compatibility confirmed

Files Modified

  • apps/routerconsole/java/src/net/i2p/router/web/FormHandler.java

Author: Lance James, Unit 221B, Inc - aka 0x90

Critical security fix addressing CWE-352 (Cross-Site Request Forgery):

Changes made:
- Remove dangerous CSRF bypass when password authentication is enabled
- Implement multi-layer CSRF token validation with fallback support
- Add constant-time string comparison to prevent timing attacks
- Enhance nonce generation with more secure token creation (256-bit)
- Provide session-specific token framework (foundation for future enhancement)
- Maintain backward compatibility with existing token system

Security improvements:
- All forms now require CSRF validation regardless of authentication mode
- Stronger token generation using multiple cryptographic random values
- Defense against timing attacks on token comparison
- Proper error messages for invalid token attempts
- Future-ready architecture for session-isolated tokens

This fix prevents unauthorized state-changing requests by ensuring all form
submissions include valid CSRF tokens, eliminating the authentication bypass
vulnerability and strengthening overall CSRF protection.

Author: Lance James, Unit 221B, Inc
@zzzi2p
Copy link
Contributor

zzzi2p commented Aug 21, 2025

Agreed we shouldn't disable the token check if password is enabled. I'll apply that part of it.

The rest of it I'm skeptical. 64 bit tokens seems plenty, and the timing attack vector seems implausible.

If we do want something longer, we should generate it with one call to nextBytes(byte[]), not 4 calls to nextLong() with 4 string appends.

There's also no need for 'backward compatibility' code, this is just a string stuck in every web form on the fly.

github-actions bot pushed a commit to eyedeekay/i2p.i2p that referenced this pull request Aug 22, 2025
Adapted from Github PR i2p#118 thanks Lance James
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants