T09 · Insecure Skill Coding Practices
Warning
- Location
- security.md:55
- Finding
- Predictable Hardcoded Secret in Signed URL Configuration Example## Vulnerability Details **File Location**: `security.md:55` **Vulnerability Type**: Hardcoded cryptographic secret in deployable configuration guidance **Risk Level**: Medium **Complete Code Snippet**: ```nginx secure_link $arg_md5,$arg_expires; secure_link_md5 "$secure_link_expires$uri secret"; ``` ### Technical Analysis The `secure_link_md5` directive constructs the value used to validate signed download URLs. The example embeds the literal string `secret` as signing-key material without clearly identifying it as a placeholder that must be replaced. If an operator copies this configuration unchanged, the signing key becomes publicly predictable. Because the protected URI and expiration timestamp are also available to a requester, an attacker can reproduce the expected MD5 input and generate a matching URL signature. The `secure_link` mechanism would then accept attacker-generated links as authentic. This is an insecure example rather than evidence of an exposed production credential, but the surrounding text presents it as configuration that can be used for expiring signed URLs. Its copy-and-deploy nature creates a realistic misconfiguration risk. ### Attack Path 1. An operator copies the documented `secure_link` configuration without replacing `secret`. 2. The resulting Nginx configuration uses a known signing secret in production. 3. An attacker identifies the protected URI and chooses an acceptable future expiration timestamp. 4. The attacker reconstructs the configured signing input from the expiration value, URI, and known literal secret. 5. The attacker computes and encodes the signature in the format expected by Nginx. 6. The attacker submits the forged signature and expiration arguments. 7. Nginx validates the predictable signature and permits access that was intended to require an authorized signed link. ### Impact Assessment Successful exploitation can bypass the signed-link access control for re ...[truncated 355 chars]
- Remediation
- ## Remediation Suggestions - Replace the literal value with an unmistakable placeholder: ```nginx secure_link_md5 "$secure_link_expires$uri <HIGH_ENTROPY_SECRET>"; ``` - Add an explicit warning that the placeholder must never be deployed unchanged. - Generate signing secrets with a cryptographically secure random generator and sufficient entropy. - Store the real secret in a root-controlled configuration file or protected deployment secret mechanism rather than source-controlled public documentation. - Restrict configuration-file permissions to the Nginx service account and authorized administrators. - Use a different secret for each environment and application boundary. - Document a rotation procedure that temporarily accepts old and new signing schemes if uninterrupted link validity is required. - Add deployment validation that rejects known example values such as `secret`, `changeme`, or the documented placeholder. - Avoid logging full signed URLs when query parameters may expose reusable signatures.