T09 · Insecure Skill Coding Practices
Warning
- Location
- examples/README.md:191
- Finding
- Unsafe SVN Server Certificate Trust Bypass<![CDATA[ ## Vulnerability Details **File Location**: `examples/README.md:191` and `SKILL.md:54` **Vulnerability Type**: TLS certificate validation bypass **Risk Level**: Medium ### Vulnerable Code ```bash svn checkout --trust-server-cert https://svn.example.com/repo ``` The same unsafe option is also presented in `SKILL.md:54`: ```text --trust-server-cert ``` ### Technical Analysis The documentation recommends `--trust-server-cert` as a normal checkout option without requiring certificate fingerprint verification or restricting its use to a specific, previously verified certificate. Trusting an unverified server certificate weakens the authentication guarantees provided by TLS. If an Agent follows this guidance in an environment affected by DNS spoofing, network interception, a compromised proxy, or an incorrectly configured repository URL, it may accept a certificate presented by an attacker-controlled SVN endpoint. This can allow the endpoint to impersonate the intended repository server. The option does not independently create a network interception condition, but it removes an important protection that would otherwise warn the user or stop the connection. ### Attack Path 1. A user asks the Agent to check out an SVN repository. 2. The attacker gains a network interception position, compromises DNS resolution, controls a proxy, or persuades the user to use an attacker-controlled repository endpoint. 3. The malicious endpoint presents an untrusted or mismatched TLS certificate. 4. The Agent follows the documented example and invokes `svn checkout` with `--trust-server-cert`. 5. Certificate validation warnings are bypassed or accepted. 6. The Agent communicates with the impersonated SVN server. 7. Depending on the SVN authentication workflow, repository credentials, authentication tokens, checked-out source content, or future committed content may be exposed to the attacker. ### Impact Assessment Successful exploitation may compromise the confide ...[truncated 632 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove `--trust-server-cert` from routine checkout examples. 2. Require normal CA and hostname validation for all HTTPS SVN connections. 3. For private certificate authorities, install the organization’s CA certificate into the appropriate trusted certificate store instead of bypassing validation. 4. If a self-signed certificate is unavoidable, obtain its fingerprint through a separate trusted channel and verify it before accepting the certificate. 5. Require explicit user approval before changing certificate trust behavior. 6. Document the expected repository hostname and certificate identity. 7. Prefer a scoped, one-time exception only after verification rather than permanently caching unverified trust. 8. Add a warning explaining that certificate trust bypasses must never be used merely to suppress unexpected TLS errors. ]]>