T09 · Insecure Skill Coding Practices
- Location
SKILL.md:113- Finding
TLS Certificate and Hostname Verification Disabled for Authenticated Odoo Connections
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 113-120; repeated at lines 335-339
Vulnerability Type: Improper certificate validation
Risk Level: HighVulnerable Code
python # 2. SSL bypass ctx = ssl.create_default_context() ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE # 3. Connect common = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/common', context=ctx) uid = common.authenticate(db, user, password, {}) models = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/object', context=ctx)The same insecure configuration is recommended again in the error-handling guidance:
python ctx = ssl.create_default_context() ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE common = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/common', context=ctx)Technical Analysis
The Skill explicitly disables both TLS certificate validation and hostname verification. TLS encryption without endpoint authentication does not establish that the client is communicating with the intended Odoo server.
The template subsequently transmits the database name, username, and reusable password through
common.authenticate. Any server presenting any certificate will be accepted. Because the Odoo URL is configurable, this affects both interception of a legitimate endpoint and accidental or malicious configuration of an impostor endpoint.Attack Path
- A user configures the Skill with a legitimate HTTPS Odoo URL and credentials.
- An attacker gains a network interception position through compromised DNS, a malicious proxy, an untrusted network, or routing manipulation.
- The attacker redirects the XML-RPC request to an attacker-controlled HTTPS server.
- The attacker presents an arbitrary or self-signed certificate.
- The client accepts the certificate because
CERT_NONEand disabled hostname checking prevent authentication failure. - The client sends the database name, username, and password to the attacker-controlled endpoint. ...[truncated 794 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove both insecure overrides:
python ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE - Use the platform trust store with certificate and hostname validation enabled:
python ctx = ssl.create_default_context() common = xmlrpc.client.ServerProxy( f'{url}/xmlrpc/2/common', context=ctx ) models = xmlrpc.client.ServerProxy( f'{url}/xmlrpc/2/object', context=ctx ) - Correct the Odoo server's certificate, hostname, and intermediate certificate chain rather than bypassing validation.
- If the deployment uses a private certificate authority, load only that trusted CA:
python ctx = ssl.create_default_context(cafile='/secure/path/company-ca.pem') - Validate the configured URL before use. Require HTTPS, reject embedded user information, and restrict the hostname to approved organizational domains where feasible.
- Prefer a revocable, least-privileged API credential over a reusable account password.
- Remove the repeated recommendation at lines 335-339 so users are not instructed to disable verification as a certificate-error workaround.
- Consider certificate pinning only where certificate rotation can be managed safely; do not use pinning as a replacement for basic hostname validation without an operational rotation plan.
- Remove both insecure overrides: