T09 · Insecure Skill Coding Practices
- Location
SKILL.md:15- Finding
Unrestricted TALLY_URL Can Transmit Sensitive Accounting Data to an Attacker-Controlled Endpoint
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:15-29
Vulnerability Type: Unrestricted network destination for sensitive accounting operations
Risk Level: MediumVulnerable Code Snippet
yaml requires: env: - TALLY_URL metadata: openclaw: requiredEnv: - TALLY_URL bins: - curl primaryCredential: TALLY_URL --- # TallyPrime (CA) Skill Connect to a **locally running** TallyPrime instance via its **XML-over-HTTP** interface. All requests are HTTP POST to `$TALLY_URL` (commonly `http://localhost:9000`) with an XML body.Technical Analysis
The Skill relies on the environment-controlled
TALLY_URLas the destination for all TallyPrime XML-over-HTTP requests. Although the documentation describes the service as locally running and giveshttp://localhost:9000as a common value, it does not require the hostname to resolve to a loopback address or otherwise validate the destination.The templates can send company names, party names, GST identifiers, addresses, invoice numbers, ledger details, voucher amounts, and other confidential accounting data to this endpoint. They also support create, alter, and cancel operations. Consequently, an attacker who can influence the environment variable can redirect sensitive payloads and operational requests to an attacker-controlled Tally-compatible HTTP service.
Using plaintext HTTP is appropriate for a strictly local loopback connection, but it presents interception and integrity risks if
TALLY_URLpoints to a remote host. The unrestricted destination therefore exceeds the minimum network scope implied by the Skill's declared local-only functionality.Attack Path
- An attacker, compromised launcher, or unsafe deployment configuration sets
TALLY_URLto an attacker-controlled HTTP endpoint. - The user asks the agent to retrieve a financial report or post an accounting voucher.
- The agent follows the Skill instructions and sends an XML request to the con ...[truncated 1296 chars]
- An attacker, compromised launcher, or unsafe deployment configuration sets
- Remediation
View remediation
Remediation Suggestions
-
Restrict the endpoint to loopback by default
- Parse
TALLY_URLbefore every request. - Permit only
localhost,127.0.0.0/8, or::1under the default local-only mode. - Resolve hostnames and verify that every resolved address is loopback to prevent DNS-based bypasses.
- Parse
-
Require explicit authorization for remote endpoints
- If remote TallyPrime access is a supported use case, stop and show the resolved scheme, hostname, port, and IP address.
- Require explicit user confirmation before transmitting accounting information to a non-loopback destination.
- Do not treat the environment variable alone as sufficient authorization.
-
Enforce transport security for remote use
- Reject plaintext HTTP for non-loopback endpoints.
- Require HTTPS with certificate verification.
- Do not use options that disable TLS or hostname validation.
-
Separate destination configuration from credentials
- Do not classify
TALLY_URLas a credential unless it actually contains secret material. - Prohibit embedded URL usernames, passwords, tokens, and query-string secrets.
- Store authentication secrets in dedicated protected environment variables or a secret manager.
- Do not classify
-
Add destination visibility
- Before read or write operations, report the sanitized destination to the user.
- Redact credentials if legacy URLs containing user information must be handled.
- Log the resolved destination and operation type without recording sensitive XML bodies.
-
Preserve write-operation safeguards
- Continue requiring explicit confirmation of the company and user intent before create, alter, or cancel operations.
- Verify the response format and import statistics rather than trusting arbitrary success text from the endpoint.
-