CWE-556, ASP.NET Misconfiguration: Use of Identity Impersonation, covers a setting that changes whose permissions an application runs with. MITRE says configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.
How it happens
MITRE explains the mechanism. Impersonation lets an ASP.NET application run with either the privileges of the client on whose behalf it is executing, or with arbitrary privileges granted in its configuration.
Both options are risky. If the app runs as the client, then whatever the client is allowed to do, the app can now do for code paths the client influences. If it runs with configured credentials, those credentials may be broader than any single page needs, and every page now has them.
<!-- Risky: the application runs under a configured identity -->
<system.web>
<identity impersonate="true" userName="DOMAIN\svc-app" password="..." />
</system.web>
What an attacker gains
MITRE lists gaining privileges or assuming identity. A flaw anywhere in the application, such as an injection bug, now runs with the impersonated identity's rights. A small bug becomes a larger one because of what the process is allowed to touch.
How to find it
- Search configuration files for the impersonation setting.
- Note which identity the application actually runs as and what that account can reach.
- Review the account's file, database and network permissions against what the app needs.
How to fix it
MITRE's mitigation: use the least privilege principle.
- Run the application under a dedicated account that has only the rights it needs.
- Avoid blanket impersonation. If a particular operation needs another identity, use it for that operation only.
- Review the account's permissions regularly and remove unused ones.
- Do not store the impersonation password in configuration in plain text.
Quick check
Why does impersonation make other bugs worse?
Code that runs under an impersonated identity inherits its rights, so any flaw can act with them.
