T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:310
- Finding
- Unsafe Default HSTS Policy Conflicts with Explicit-Consent Requirement## Vulnerability Details **File Location**: `SKILL.md`, line 310; related safety rule at line 467 **Vulnerability Type**: Unsafe security configuration **Risk Level**: Medium **Vulnerable configuration:** ```nginx add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; ``` **Conflicting safety rule:** ```text NEVER set HSTS preload without explicit user consent. Preload is irreversible -- once submitted to the HSTS preload list, the domain must serve HTTPS forever. ``` ### Technical Analysis The supplied production configuration unconditionally enables a two-year HSTS policy with `includeSubDomains` and the `preload` directive. However, the Skill's own safety rules require explicit user consent before setting HSTS preload. Once a browser receives this header over HTTPS, it can cache the requirement to use HTTPS for the parent domain and every subdomain for up to 63,072,000 seconds. The `preload` token also makes the domain eligible for submission to browser preload lists. Merely sending this token does not itself submit the domain, but it creates a dangerous default and facilitates a longer-lived, difficult-to-reverse policy. This is an insecure configuration practice rather than malicious persistence. The separate instructions to enable Nginx and configure certificate renewal are proportionate to the declared reverse-proxy and automated-TLS functionality. ### Attack Path 1. An agent follows Phase 6 and copies the provided hardened Nginx configuration without modification. 2. Nginx begins returning the HSTS header containing `includeSubDomains`, a two-year `max-age`, and `preload`. 3. Browsers cache the policy for the parent domain and apply it to all subdomains. 4. Any subdomain that lacks valid HTTPS becomes inaccessible to affected clients because browsers automatically upgrade HTTP requests to HTTPS. 5. If the domain is subsequently submitted to an HSTS preload list, the be ...[truncated 738 chars]
- Remediation
- ## Remediation Suggestions Use a conservative HSTS policy by default: ```nginx add_header Strict-Transport-Security "max-age=31536000" always; ``` Apply the following hardening plan: 1. Do not enable `includeSubDomains` until every current subdomain supports HTTPS with a valid certificate. 2. Do not add `preload` until the user gives explicit informed consent and understands the preload-list removal process. 3. Begin with a short `max-age`, such as 300 seconds, during validation and increase it gradually after confirming that HTTPS works reliably. 4. Inventory current and anticipated subdomains before enabling `includeSubDomains`. 5. Confirm that certificate renewal and monitoring are operational before deploying a long-lived policy. 6. Make consent an explicit prerequisite in Phase 6 rather than relying only on the later safety rule. 7. Clearly state that the `preload` directive alone does not submit a domain; submission to the browser preload service is a separate action that must also require explicit approval.