T09 · Insecure Skill Coding Practices
Error
- Location
scripts/script.sh:6- Finding
Security-sensitive inputs are stored and disclosed in plaintext
- Content
View full analysis
> "$DATA_DIR/history.log"; } ``` ```bash store) shift if [ $# -eq 0 ]; then echo "Recent store entries:" tail -20 "$DATA_DIR/store.log" 2>/dev/null || echo " No entries yet. Use: consent store " else local input="$*" local ts=$(date '+%Y-%m-%d %H:%M') echo "$ts|$input" >> "$DATA_DIR/store.log" local total=$(wc -l < "$DATA_DIR/store.log") echo " [Consent] store: $input" echo " Saved. Total store entries: $total" _log "store" "$input" fi ;; ``` The same plaintext logging pattern is repeated for security-oriented commands including `generate`, `check-strength`, `rotate`, `hash`, and `verify` in `scripts/script.sh:141-309`. ### Technical Analysis The Skill documentation encourages users to submit API keys, database passwords, credentials, tokens, passphrases, and consent records. The implementation writes each submitted value verbatim to a command-specific log and then writes it again to `history.log`. It also echoes the value to standard output. No encryption, one-way hashing, secret redaction, access-control validation, or restrictive `umask` is applied. `mkdir -p` therefore relies on the caller's ambient umask. Under a common `0022` umask, newly created files can be readable by other local users. The command named `hash` also follows this logging pattern rather than hashing its input. The argument-taking branches currently use `local` outside a function, which normally causes Bash execution to fail at that statement. This functional defect limits ordinary command-line exploitation in the current version, but it does not ...[truncated 1479 chars]- Remediation
View remediation