Fn call approval roll up

[garland3]

No description provided.

To fix the issue, any user-provided input logged by the application must be sanitized to prevent log injection. In the affected code, the handle_approval_response method logs two fields: tool_call_id (already safely sanitized), and approved, which can (in practice) be any type due to lack of prior validation. We should ensure that approved is passed through the same sanitize_for_logging function before logging, converting it to a string if needed. This change should be implemented in backend/application/chat/approval_manager.py, specifically on line 112, replacing direct use of approved with sanitize_for_logging(approved).

The fix simply updates the log statement, so no new imports or methods are needed. The change should preserve original code behavior.

To robustly prevent log injection, ensure the utility function sanitize_for_logging comprehensively strips all characters that could inject unwanted newlines into log entries. In addition to the current ASCII control characters stripped by the regex, you should explicitly remove Unicode newline characters (such as \u2028 and \u2029), since the current regular expression does not match these.
The best fix is to modify sanitize_for_logging in backend/core/utils.py so it additionally removes Unicode line separator characters (\u2028, \u2029) and standard newlines and carriage returns (which are already covered by the regex but for clarity/robustness can be handled explicitly as well).
Only the utility function needs changing: all log invocations already sanitize their parameters via this function, so strengthening the sanitization will fix all downstream uses, including in backend/application/chat/approval_manager.py.

---

The problem arises because the approved parameter, intended to be a boolean, is logged without sanitization. Due to dynamic typing and the nature of the WebSocket payload, a user could craft a value (for example, a string containing newlines) that results in log injection—potentially creating forged or misleading log entries.

General fix:
All user-provided (or indirectly user-controllable) data written to log entries must be sanitized to remove or escape log-forging characters (newline, carriage return, etc.).

Detailed fix:

• Wrap the approved value with the same or equivalent sanitization method used for other fields (sanitize_for_logging()).
• Change the relevant log statement on line 125 of backend/application/chat/approval_manager.py from:

  logger.info(f"Approval response handled for tool {sanitize_for_logging(request.tool_name)}: approved={approved}")

  to:

  logger.info(f"Approval response handled for tool {sanitize_for_logging(request.tool_name)}: approved={sanitize_for_logging(approved)}")

• No additional imports or helper methods are needed, since sanitize_for_logging is already imported and used.

No changes are needed in backend/main.py because logging is already wrapped with sanitize_for_logging there.

---

To fix the log injection vulnerability, all user-controlled data interpolated into log messages must be sanitized to remove log control characters that can cause log forging—most importantly, line breaks (\n and \r). The simplest approach here is to replace or remove these characters from any input field that originates from the WebSocket before using them in a log message.

The fix should be applied in backend/main.py at the point where message_type is logged (line 228). To ensure safety and maintain code clarity, create a small helper function named sanitize_for_logging elsewhere in the file, which replaces \n/\r with empty strings or another safe character, and call this function on message_type when logging. All other functionality remains unchanged.

Implementation steps:

• Locate the log statement on line 228 and wrap message_type with a sanitization function.
• Define the sanitization function in backend/main.py.
• No new dependencies are required; use built-in string methods.
• Ensure sufficient context is provided for the log message.

To address the detected "statement has no effect" error at line 306 (await approval_task), the statement should be updated to assign its (discarded) result to a dummy variable, commonly named _. This makes the intention clear that any return value or exception from the task is being captured (or purposely ignored), and the statement no longer appears to have no effect. Specifically, in backend/tests/test_approval_manager.py, line 306 should be changed to _ = await approval_task.

---