fix: escape NUL byte in LDAP filter values#122
Conversation
`0x0.toString()` evaluates to "0", so the digit `0` was being replaced with `\00`. JNDI then DN-decoded `\00` to a real NUL byte — username `leo04` ended up stored in LDAP as `leo<NUL>4` (`leo\004` in DN form). Same corruption hit any email/username containing the digit 0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe LDAP escaping logic is updated to detect NUL characters using direct Unicode escape notation ( ChangesLDAP NUL Character Escaping Fix
Estimated code review effort🎯 2 (Simple) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
Summary
escape()calledreplace(0x0.toString(), "\\00"), butInt.toString()returns"0"— so every literal digit0in usernames/emails was replaced with\00. JNDI then DN-decoded\00back to a real NUL byte and stored that in LDAP. Usernameleo04was stored asleo<NUL>4(leo\004in DN form). The email-uniqueness check inCreateUsercould also spuriously pass for emails containing0.Fix: replace the bogus marker with the actual NUL escape. Added
EscapeSpeccovering all five RFC 2254 special chars plus a regression case for the digit0.Cleanup needed (manual, post-merge)
uidneed to be renamed (e.g.leo<NUL>4→leo04).0.Test plan
./gradlew testpasses (couldn't run locally — no JDK in my env)Summary by CodeRabbit
Release Notes
Bug Fixes
Tests