T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/sentinel.py:41- Finding
Hard-Coded Application Credential in Source Code
- Content
View full analysis
dict: timestamp = str(int(time.time())) sign = hashlib.md5(f"{APP_ID}&{timestamp}&{APP_KEY}".encode()).hexdigest() ``` ### Technical Analysis The application identifier and application key used to sign AutoGLM API requests are embedded directly in distributable source code. Any party with access to the Skill package can recover these values without requiring elevated local privileges. The application key is incorporated into an unsalted MD5 digest with a predictable application identifier and timestamp. MD5 is not appropriate for modern cryptographic authentication, and this construction is not a standard message authentication code. Although changing the signing algorithm may depend on the API provider's protocol, embedding the signing key in source code removes its confidentiality entirely. The bearer token retrieved from the local token service is separate from this application key. Therefore, the exposed key alone does not demonstrate complete account compromise; successful unauthorized API use may also require a valid bearer token or an API-side authentication weakness. ### Attack Path 1. An attacker downloads or otherwise obtains a copy of the Skill package. 2. The attacker opens `scripts/sentinel.py` and extracts `APP_ID` and `APP_KEY`. 3. The attacker reproduces the signing operation using a current Unix timestamp. 4. The attacker obtains a valid bearer token through an independent compromise, their own authorized environment, or another weakness outside the audited project. 5. The attacker submits signed requests to the fixed AutoGLM search endpoint using the exposed application identity. 6. If server-side controls d ...[truncated 855 chars]- Remediation
View remediation