[
https://issues.apache.org/jira/browse/ZOOKEEPER-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andor Molnar updated ZOOKEEPER-5082:
------------------------------------
Description:
Follow up on ZOOKEEPER-3979 which hasn't implemented sanitization of the
username input before logging it, hence the original log forgery issue hasn't
been resolved.
Something similar to what has been done in EnsembleAuthenticationProvider in
ZOOKEEPER-5058 would be preferable.
*Update*
Let me add more context to this. Forged audit log entries can come from
multiple sources and *AuthUtil.getUser()* is one of them:
AuditHelper calls request.getUsersForAudit() which chains through
AuthUtil.getUsers() → DigestAuthenticationProvider.getUserName(), producing the
unsanitized string that gets embedded into the AuditEvent.
Another example of audit logger of {*}setAcl request{*}:
When a setACL request is audit-logged, AuditHelper.addAuditLog() reads the
request ACLs and passes them to ZKUtil.aclToString(). That helper concatenates
the ACL scheme, raw id, and permissions directly into a single string. Finally,
AuditEvent.toString() emits the entire audit record.
We need a solution which catches all possible call chains and makes sure no
invalid character is emitted in the audit log. One possible solution is to
sanitizie the audit event value in AuditEvent.toString() method.
was:
Follow up on ZOOKEEPER-3979 which hasn't implemented sanitization of the
username input before logging it, hence the original log forgery issue hasn't
been resolved.
Something similar to what has been done in EnsembleAuthenticationProvider in
ZOOKEEPER-5058 would be preferable.
*Update*
Let me add more context to this. Forged audit log entries can come from
multiple sources and *AuthUtil.getUser()* is one of them:
{{AuditHelper}} calls {{request.getUsersForAudit()}} which chains through
{{AuthUtil.getUsers()}} → {{{}DigestAuthenticationProvider.getUserName(){}}},
producing the unsanitized string that gets embedded into the {{AuditEvent.}}
{{{{Another example of audit logger of *setAcl* request:}}}}
When a {{setACL}} request is audit-logged, {{AuditHelper.addAuditLog()}} reads
the request ACLs and passes them to {{{}ZKUtil.aclToString(){}}}. That helper
concatenates the ACL scheme, raw id, and permissions directly into a single
string. Finally, {{AuditEvent.toString()}} emits the entire audit record.
{{We need a solution which catches all possible call chains and makes sure no
invalid character is emitted in the audit log. One possible solution is to
sanitizie the audit event value in AuditEvent.toString() method.}}
> Remove special characters from username in audit logs
> -----------------------------------------------------
>
> Key: ZOOKEEPER-5082
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5082
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.10.0, 3.9.5, 3.8.6
> Reporter: Andor Molnar
> Assignee: Andor Molnar
> Priority: Major
>
> Follow up on ZOOKEEPER-3979 which hasn't implemented sanitization of the
> username input before logging it, hence the original log forgery issue hasn't
> been resolved.
> Something similar to what has been done in EnsembleAuthenticationProvider in
> ZOOKEEPER-5058 would be preferable.
> *Update*
> Let me add more context to this. Forged audit log entries can come from
> multiple sources and *AuthUtil.getUser()* is one of them:
> AuditHelper calls request.getUsersForAudit() which chains through
> AuthUtil.getUsers() → DigestAuthenticationProvider.getUserName(), producing
> the unsanitized string that gets embedded into the AuditEvent.
> Another example of audit logger of {*}setAcl request{*}:
> When a setACL request is audit-logged, AuditHelper.addAuditLog() reads the
> request ACLs and passes them to ZKUtil.aclToString(). That helper
> concatenates the ACL scheme, raw id, and permissions directly into a single
> string. Finally, AuditEvent.toString() emits the entire audit record.
> We need a solution which catches all possible call chains and makes sure no
> invalid character is emitted in the audit log. One possible solution is to
> sanitizie the audit event value in AuditEvent.toString() method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
