Unsafe Reflection
ID |
csharp.unsafe_reflection |
Severity |
high |
Resource |
Injection |
Language |
CSharp |
Tags |
CWE:470, NIST.SP.800-53, OWASP:2021:A3, PCI-DSS:6.5.1 |
Description
Unsafe Reflection occurs when an application uses reflection in an insecure manner, potentially allowing an attacker to manipulate the class loader or execute arbitrary code. Reflection is powerful, but it must be used carefully to avoid introducing security vulnerabilities.
Rationale
Unsafe Reflection vulnerability (CWE: 470) arises when an application dynamically loads and executes classes determined at runtime without sufficient validation.
This can lead to unauthorized code execution, which represents a severe security threat. For example, if an attacker can influence the class name that a reflection call uses, they can potentially load malicious classes.
The following is an example of a reflective call that is vulnerable to unsafe reflection:
using System.Reflection;
using Microsoft.AspNetCore.Http;
public class UnsafeReflection
{
// This is a VULNERABLE reflective call, for processing a web request
// taking the class name and method name from the request without validation
public static void ProcessRequest(HttpRequest req)
{
// External input, manipulated by attacker
string className = req.Query["className"];
string methodName = req.Query["methodName"];
// FLAW: Using input for type name without validation
Type type = Type.GetType(className);
if (type == null)
{
Log( "Type not found." );
return;
}
object instance = Activator.CreateInstance(type);
// FLAW: Using method name from input without validation
MethodInfo method = type.GetMethod(methodName, new Type[] { typeof(HttpRequest) });
if (method == null)
{
Log( "Method not found." );
return;
}
// The attacker can choose code to run from the types available to the .NET runtime
method.Invoke(instance, new object[] { req });
}
}
In the above code, className
and methodName
are supplied externally, and no validation or checks are performed on these inputs. This can allow an attacker to supply an unintended or even malicious class and method for execution.
Remediation
To remediate unsafe reflection vulnerabilities, follow these guidelines:
-
Validate Input: Always validate the input strings used to form a reflective call. Employ whitelisting strategies to ensure only known and safe class names are used.
-
Least Privilege: Give the minimal permissions necessary for the reflection to operate. This decreases the impact of code execution should an unsafe reflection vulnerability be exploited.
-
Code Review and Testing: Perform thorough code reviews and security testing to identify potential insecure reflection points early in the development process.
-
Use Alternative Designs: Whenever possible, consider alternative designs that do not rely on reflection, which can often be less error-prone and more efficient.
In C#, there are different ways to select behavior from a whitelist of known good functions. These functions could be chosen by user input and include delegates or lambdas.
Configuration
The detector has the following configurable parameters:
-
sources
, that indicates the source kinds to check. -
neutralizations
, that indicates the neutralization kinds to check.
Unless you need to change the default behavior, you typically do not need to configure this detector.
References
-
CWE-470 : Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
-
Unsafe use of Reflection. in OWASP Vulnerabilities.