T09 · Insecure Skill Coding Practices
- Location
SKILL.md:154- Finding
Plaintext Storage of Identity, Authentication, Banking, and Payment-Card Data
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 154-187
Vulnerability Type: Plaintext storage and aggregation of highly sensitive data
Risk Level: HighVulnerable Code Snippet
text ==== Batch Registration Data Template ==== Legal Person ID: {id} Legal Person Name: {name} Legal Person Name in Pinyin: Date of Birth: Identity Card Number: Email: {auto_generated} Email Password: {auto_generated} eBay Account: {same as email} eBay Password: {auto_generated} eBay Username: {randomly generated by script} Payoneer Email: {same as above} Payoneer Password: {auto_generated} eBay Phone Number: {record after receiving SMS} Payoneer Phone Number: {record after receiving SMS} eBay Credit Card Number: eBay Credit Card Expiration Date: eBay Credit Card CVV: Payoneer Bank Name: Payoneer Bank Account Number: Payoneer Bank Address: Company Name in Chinese: Company Name in English: Unified Social Credit Code: Company Registration Date: Company Postal Code: Company Address in Chinese: Company Address in English:The snippet above is an English rendering of the plaintext template in
SKILL.md; the original fields appear at the cited location.Technical Analysis
The Skill instructs operators to place government identity details, account identifiers, three passwords, telephone numbers, full payment-card details—including CVV—and bank-account information into a plaintext registration file. The documented directory layout creates one such file for each of up to 50 legal persons under a predictable desktop directory.
This design violates data-minimization and secure-secret-storage principles. It aggregates several independent authentication and financial factors in one location, substantially increasing the value of a single file-system compromise. The Skill specifies no encryption at rest, credential-vault integration, field-level access controls, masking, retention period, secure deletion, backup exclusions, or file-permission requirem ...[truncated 1959 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not store CVV values. Remove the CVV field from all templates and ensure it is used only transiently during an authorized payment interaction.
- Move credentials into a secret store. Store passwords in an operating-system credential vault or managed secrets service rather than text, JSON, spreadsheet, or report files.
- Encrypt required records at rest. Use authenticated encryption with keys kept separately from the data. Apply field-level encryption to identity, card, and bank-account data.
- Separate data domains. Do not aggregate identity records, passwords, recovery channels, and payment details in the same file or datastore.
- Apply least-privilege access controls. Restrict the data directory to the designated operator account and deny access to unrelated users and services.
- Prevent secondary copies. Exclude sensitive records from cloud synchronization, plaintext backups, temporary files, logs, generated reports, and source-control repositories.
- Mask output fields. Queue files, dashboards, logs, and Excel reports should display only redacted values, such as the last four digits of an account number.
- Minimize collection and retention. Collect only fields required for the immediate authorized operation, define short retention periods, and securely delete records once no longer needed.
- Add operational safeguards. Document file-permission requirements, incident-response procedures, access auditing, and secure disposal requirements.
- Protect generated reports. Ensure report exports omit passwords, CVVs, full card numbers, identity numbers, and complete bank-account details.