T09 · Insecure Skill Coding Practices
Warning
- Location
- references/aspnet-core.md:180
- Finding
- Insecure JWT Signing Secret Configuration Template## Vulnerability Details **File Location**: `references/aspnet-core.md`, lines 180-188 **Vulnerability Type**: Hardcoded and predictably weak cryptographic secret **Risk Level**: Medium ### Vulnerable Code ```json // appsettings.json { "JwtSettings": { "Secret": "your-secret-key", "Issuer": "your-app", "Audience": "your-audience", "ExpiryMinutes": 60 } } ``` ### Technical Analysis The documented configuration places a predictable JWT signing secret directly in an application settings file. Although the value appears to be a placeholder, the example does not direct users to retrieve the secret from an environment variable, development secret store, or managed production vault. Applications created by copying this template may retain the placeholder or replace it with a real secret that is subsequently committed to source control. The authentication example later derives a symmetric signing key from this value. Anyone who knows or can predict the secret can create JWTs with arbitrary identity, claim, or role values that pass signature validation, subject to the configured issuer and audience checks. ### Attack Path 1. A developer copies the documented JWT configuration into an application. 2. The application is deployed with the placeholder secret, another weak secret, or a production secret committed to source control. 3. An attacker obtains the key by guessing the documented value, reading leaked configuration, or accessing source-code history. 4. The attacker creates a JWT containing a chosen user identity and privileged claims such as an administrative role. 5. The attacker signs the token using the recovered symmetric key and supplies the expected issuer and audience. 6. The application accepts the forged token and authorizes requests according to the injected claims. ### Impact Assessment Successful exploitation can allow authentication bypass and impersonation of arbitrary us ...[truncated 332 chars]
- Remediation
- ## Remediation Suggestions - Do not place JWT signing secrets or realistic placeholder values in committed configuration files. - Load production keys from a managed secret store such as Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, or an equivalent platform facility. - Use .NET user-secrets only for local development and environment variables or workload identity for deployment-time configuration. - Generate a cryptographically random key with sufficient entropy for the selected algorithm. - Add startup validation that rejects missing, default, short, or known placeholder values. - Rotate any key that may have been committed or deployed, and invalidate tokens signed with the old key. - Prefer asymmetric signing where appropriate so token-verifying services do not require access to the private signing key. - Replace the example with a non-secret configuration reference and an explicit secure provisioning example.