T09 · Insecure Skill Coding Practices
- Location
scripts/script.sh:5- Finding
Undisclosed Plaintext Persistence and Ineffective Deletion of Potentially Sensitive HR Data
- Content
View full analysis
Vulnerability Details
File Location:
scripts/script.sh, lines 5-8, 31, and 49-57
Vulnerability Type: Plaintext sensitive-data storage and ineffective deletion
Risk Level: MediumVulnerable Code
bash DATA_DIR="${HR_TOOLKIT_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/hr-toolkit}" DB="$DATA_DIR/data.log" mkdir -p "$DATA_DIR"bash _log() { echo "$(date '+%m-%d %H:%M') $1: $2" >> "$DATA_DIR/history.log"; }bash cmd_add() { echo "$(date +%Y-%m-%d) $*" >> "$DB"; echo " Added: $*" _log "add" "${1:-}" } cmd_remove() { echo " Removed: $1" _log "remove" "${1:-}" }Technical Analysis
The
addcommand writes the complete supplied argument string to the persistentdata.logfile without encryption, redaction, retention limits, or an explicit user warning. It also records the first argument inhistory.log.This project is presented as an HR toolkit whose documented usage includes employee names, job information, onboarding details, and departure circumstances. Consequently, arguments may contain personal or employment-related information. The script does not establish restrictive permissions with
umask 077or explicitchmodoperations; resulting access permissions therefore depend on the invoking environment's currentumask.The
removecommand compounds this problem by printingRemovedwithout modifyingdata.log. It merely adds another history entry. A user can consequently receive a false indication that an HR record was deleted while the original plaintext record remains stored.Storage is also not disclosed in the primary skill documentation. The command implementation therefore persists data beyond the immediate operation without presenting retention, consent, deletion, or data-minimization controls.
Attack Path
- A user invokes
hr-toolkit addwith an employee name, role, departure reason, or other HR-related information ...[truncated 1347 chars]
- A user invokes
- Remediation
View remediation
Remediation Suggestions
- Avoid storing command arguments unless persistence is explicitly requested and documented.
- Clearly disclose what data is stored, where it is stored, how long it is retained, and how users can delete it.
- Establish restrictive permissions before creating storage:
bash umask 077 mkdir -p -- "$DATA_DIR" chmod 700 -- "$DATA_DIR" touch -- "$DB" "$DATA_DIR/history.log" chmod 600 -- "$DB" "$DATA_DIR/history.log" - Minimize log contents. Do not copy employee names or complete command arguments into history logs; record only non-sensitive operational metadata when necessary.
- Implement actual deletion in
cmd_remove, using a stable record identifier rather than ambiguous text matching. Report success only after verifying that the target record was removed. - Provide commands for listing retained records, defining retention periods, and securely purging stored data where supported.
- Consider authenticated encryption if sensitive HR records must be retained, with keys stored separately from the data files.
- Add automated tests confirming that deletion removes the intended record and that created directories and files are not accessible to other users by default.