CWE-13 is a blunt one. A plaintext password is stored in an ASP.NET configuration file. Anyone who can read the file can use the password, which makes the protected resource an easy target.
MITRE lists the impact as access control: gaining privileges or assuming identity. The password is the identity.
How it happens
Configuration files are where connection strings live, and a connection string often carries a username and password. It is the fastest way to make the app talk to its database, so it gets committed, copied to a server and left alone.
From there the file spreads. It lands in source control history, in build artifacts, in backups, on a developer laptop, in a support bundle. Each copy is another place the password can leak from, and removing it from the latest commit does not remove it from the past.
What an attacker gains
With the password, an attacker acts as the service account. That could be a database login, a service credential or an administrator. They do not need to find a code flaw, because they hold a valid key.
How to find it
Search configuration files across your repositories and deployed servers for password fields and connection strings that contain credentials. Search history as well as the current tree. A secrets scanner automates this and flags values that look like credentials.
Click through it at your own pace, or open it full screen.
How to fix it
- Move the secret out of the file. Load it at runtime from environment variables or a managed secret store.
- Prefer authentication that uses no stored password, such as an identity assigned to the host.
- Restrict who can read configuration files on the server.
- Rotate the exposed password. Assume it has been seen, since it sat in plaintext.
- Purge it from history where you can, and treat anything you cannot purge as compromised.
A configuration entry that points to a secret by name is safe to commit. One that holds the secret is not.
Quick check
Is it enough to delete the password from the file?
No. Older commits, backups and copies still hold it. Rotate the password so the leaked value stops working.
Does encrypting the file solve it?
Only if the decryption key is kept somewhere the attacker cannot reach. Storing the key beside the file moves the problem without fixing it.
