Restructure openscad-0001 (was in wrong dir, Java test) into proper openscad-0001/ with TICKET.md and Python test. New openscad-0002 patches PolySetBuilder::endPolygon + appendPolySet std::find on colors_ vector -> unordered_map; Color4f already has std::hash. New openscad-0003 patches OctoPrint::requestApiKey and getJsonData to stop logging API responses verbatim (app_token + api responses exposed under --debug). MOADs 0002/0003/0005 CLEAN.
1.5 KiB
openscad-0003 — CWE-312 OctoPrint requestApiKey logs app_token verbatim
MOAD: 0004 (Logged Secret, CWE-312) Severity: MEDIUM UNDF: (pending)
Location
src/gui/OctoPrint.cc — requestApiKey() and getJsonData()
Pattern
OctoPrint integration uses PRINTDB("Response: %s", ...) to log full JSON
response bodies verbatim when --debug mode is active.
Two specific exposure points:
-
requestApiKey()(line ~131): logs the full JSON response fromPOST /plugin/appkeys/request. That response containsapp_token, a short-lived credential used to poll for key approval. Logged verbatim. -
getJsonData()(line ~71): logs the full JSON response for ANY GET endpoint. This includes/slicing,/version, and any other OctoPrint API response. These responses may contain printer configuration, file paths, and keys depending on the OctoPrint plugin and version.
The most concrete leak: app_token in requestApiKey is logged, then later
used to poll for the final api_key (also stored in settings). An attacker
with access to OpenSCAD debug logs (or the terminal session) obtains the token
needed to observe the key exchange.
Fix
Redact the sensitive field before logging. For requestApiKey, extract
app_token from the parsed JSON object and log a redacted placeholder instead
of the raw response. For getJsonData, remove the blanket response logging or
filter known-sensitive keys.
Patch
patch/openscad-0003-octoprint-token-log-redact.patch