T09 · Insecure Skill Coding Practices
- Location
scripts/rewrite.py:15- Finding
TLS Certificate and Hostname Verification Disabled
- Content
View full analysis
Vulnerability Details
File Location:
scripts/rewrite.py, lines 15-20 and 37-44
Vulnerability Type: Improper TLS certificate validation
Risk Level: HighVulnerable Code
python # Service endpoint SERVICE_URL = "https://192.144.154.90/demo/a2m/resource" # Skip self-signed certificate verification SSL_CONTEXT = ssl.create_default_context() SSL_CONTEXT.check_hostname = False SSL_CONTEXT.verify_mode = ssl.CERT_NONEpython try: resp = urllib.request.urlopen(req, context=SSL_CONTEXT, timeout=200) data = json.loads(resp.read().decode("utf-8")) return data except urllib.error.HTTPError as e: if e.code == 402: payment_needed = e.headers.get("Payment-Needed", "") body = e.read().decode("utf-8", errors="replace")Technical Analysis
The script creates an SSL context but explicitly disables both certificate-chain validation and hostname verification. Consequently, HTTPS encryption does not authenticate the remote service. Any certificate presented during the TLS handshake will be accepted, including a certificate controlled by an attacker.
The script transmits up to 30,000 characters of potentially confidential academic manuscript content through this insecure connection. It also trusts the returned JSON response, HTTP status, and
Payment-Neededheader. A network-positioned attacker can therefore impersonate the rewrite service and inspect or modify application data without needing a certificate trusted by the client.The use of a bare IP address increases deployment pressure to bypass hostname validation but does not make disabling TLS validation safe.
Attack Path
- A user invokes the Skill with unpublished or otherwise sensitive manuscript text.
- The script builds a JSON request containing that text and connects to
192.144.154.90. - An attacker obtains a network interception position, such as through a compromised gateway, h ...[truncated 1213 chars]
- Remediation
View remediation
Remediation Suggestions
-
Deploy the service under a DNS hostname with a valid certificate issued by a trusted certificate authority.
-
Remove the custom context that disables verification. Use the secure defaults:
python resp = urllib.request.urlopen(req, timeout=200)Alternatively, retain an explicit default context without weakening it:
python ssl_context = ssl.create_default_context() resp = urllib.request.urlopen( req, context=ssl_context, timeout=200, ) -
Do not set
check_hostnametoFalseorverify_modetossl.CERT_NONEin production. -
If a private certificate authority is operationally required, install only that CA as a trust anchor and preserve hostname verification rather than accepting arbitrary certificates.
-
Validate the structure, expected content types, and size of service responses before consuming them.
-
Treat HTTP 402 headers and bodies as untrusted data. Authenticate and validate payment metadata before presenting it for authorization or initiating any payment workflow.
-
Inform users that submitted manuscript text is transferred to an external service and may contain sensitive information.
-
Add automated tests or static-analysis rules that fail builds when certificate verification is disabled.
-
