T09 · Insecure Skill Coding Practices
Error
- Location
- v2ex_monitor.py:78
- Finding
- Authenticated API Requests Disable TLS Certificate Verification<![CDATA[ ## Vulnerability Details **File Location**: `v2ex_monitor.py:78-80`, `v2ex_monitor.py:106-108`, `v2ex_monitor.py:137-139`, and `v2ex_mcp.py:33-35` **Vulnerability Type**: Improper certificate validation **Risk Level**: High ### Vulnerable Code `v2ex_monitor.py:78-81`: ```python ctx = ssl.create_default_context() ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE with urllib3.PoolManager(ssl_context=ctx) as pool: ``` The same pattern is repeated for topic details at lines 106-108 and notifications at lines 137-139. `v2ex_mcp.py:33-39`: ```python self.ctx = ssl.create_default_context() self.ctx.check_hostname = False self.ctx.verify_mode = ssl.CERT_NONE self.headers = { "Authorization": f"Bearer {api_key}", "User-Agent": "V2EX-MCP/1.0" } ``` ### Technical Analysis The clients create a normal TLS context and then explicitly disable hostname checks and certificate-chain validation. These contexts are used for authenticated requests containing the V2EX bearer token. Encryption without certificate authentication does not establish that the remote endpoint is V2EX. Any attacker capable of intercepting or redirecting network traffic can present an arbitrary certificate, terminate the connection, and receive the authorization header. The verified `requests` fallback in `v2ex_monitor.py` does not mitigate this flaw because it is only attempted after the insecure primary request fails. Globally suppressing `urllib3` warnings in `v2ex_monitor.py` further reduces the likelihood that users will notice insecure TLS behavior. ### Attack Path 1. A user configures a valid V2EX API token and invokes the monitor or MCP server. 2. An attacker obtains a network interception position, controls a proxy, compromises local DNS, or redirects traffic through a hostile access point. 3. The attacker redirects the connection intended for `www.v2ex.com` to an attacker-controlled TLS endpoint. 4. The hostile endpoint presents an untrusted or hostname-mismat ...[truncated 778 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Retain the defaults from `ssl.create_default_context()` and remove both of the following assignments: ```python ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE ``` - Use a verified `urllib3.PoolManager` directly: ```python http = urllib3.PoolManager( cert_reqs="CERT_REQUIRED", ca_certs=ssl.get_default_verify_paths().cafile, ) ``` - Apply the same correction to every request path in `v2ex_monitor.py` and to `V2EXClient` in `v2ex_mcp.py`. - Remove `urllib3.disable_warnings()`. - Fail closed when certificate validation fails instead of retrying through another unverified client. - If a private certificate authority must be supported, accept an explicit CA bundle path rather than disabling verification. - Revoke and replace any API token previously used over untrusted networks with the vulnerable versions. ]]>