T09 · Insecure Skill Coding Practices
- Location
setup.sh:39- Finding
OAuth Client Secret Stored in Plaintext Configuration
- Content
View full analysis
"$CONFIG_PATH" << EOF { "appName": "kingdoc", "appId": "$APP_ID", "appSecret": "$APP_SECRET", "scope": "user:file:write user:file:read team:file:write team:file:read", "environment": "production" } EOF echo "[OK] Config saved" ``` The Windows installer implements the same behavior: ```powershell # Save config $config = @{ appName = "kingdoc" appId = $appId appSecret = [Runtime.InteropServices.Marshal]::PtrToStringAuto( [Runtime.InteropServices.Marshal]::SecureStringToBSTR($appSecret) ) scope = "user:file:write user:file:read team:file:write team:file:read" environment = "production" } | ConvertTo-Json -Depth 3 $configPath = Join-Path $PSScriptRoot "config.json" Set-Content -Path $configPath -Value $config -Encoding UTF8 Write-Host "[OK] Config saved to config.json" -ForegroundColor Green ``` ### Technical Analysis Both installers persist the KDocs OAuth client secret as plaintext in `config.json`. The Unix installer does not create the file with owner-only permissions. The Windows installer accepts the secret as a `SecureString`, but immediately converts it to an ordinary plaintext string before writing it with inherited filesystem permissions. The configured scopes include read and write access to personal and team documents. Therefore, disclosure of this secret could allow another party to request application access tokens within the application's approved authorization scope. This behavior also conflicts with the project's security posture: while the access token remains primarily in memory, the long-lived client credential used to obtain new tokens is persisted without adequate protection. ### Attack Path 1. A user runs `setup.sh` or `setup.ps1` and suppl ...[truncated 998 chars]- Remediation
View remediation
