CA2109: Review visible event handlers
| Property | Value |
|---|---|
| Rule ID | CA2109 |
| Title | Review visible event handlers |
| Category | Security |
| Fix is breaking or non-breaking | Breaking |
| Enabled by default in .NET 8 | No |
Cause
A public or protected event-handling method was detected.
Note
This rule has been deprecated. It last shipped with Microsoft.CodeAnalysis.NetAnalyzers 7.0.0 NuGet package and the .NET 7 SDK.
The rule was removed because the threat that the analyzer warned about (an untrusted intermediary hooking a privileged event handler to a privileged event invoker) hasn't existed since .NET Framework 4.5.
Rule description
An externally visible event-handling method presents a security issue that requires review.
Do not expose event-handling methods unless absolutely necessary. An event handler, a delegate type, that invokes the exposed method can be added to any event as long as the handler and event signatures match. Events can potentially be raised by any code, and are frequently raised by highly trusted system code in response to user actions such as clicking a button. Adding a security check to an event-handling method does not prevent code from registering an event handler that invokes the method.
A demand cannot reliably protect a method invoked by an event handler. Security demands help protect code from untrusted callers by examining the callers on the call stack. Code that adds an event handler to an event is not necessarily present on the call stack when the event handler's methods run. Therefore, the call stack might have only highly trusted callers when the event handler method is invoked. This causes demands made by the event handler method to succeed. Also, the demanded permission might be asserted when the method is invoked. For these reasons, the risk of not fixing a violation of this rule can only be assessed after reviewing the event-handling method. When you review your code, consider the following issues:
Does your event handler perform any operations that are dangerous or exploitable, such as asserting permissions or suppressing unmanaged code permission?
What are the security threats to and from your code because it can run at any time with only highly trusted callers on the stack?
How to fix violations
To fix a violation of this rule, review the method and evaluate the following:
Can you make the event-handling method non-public?
Can you move all dangerous functionality out of the event handler?
If a security demand is imposed, can this be accomplished in some other manner?
When to suppress warnings
Suppress a warning from this rule only after a careful security review to make sure that your code does not pose a security threat.
Suppress a warning
If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.
#pragma warning disable CA2109
// The code that's violating the rule is on this line.
#pragma warning restore CA2109
To disable the rule for a file, folder, or project, set its severity to none in the configuration file.
[*.{cs,vb}]
dotnet_diagnostic.CA2109.severity = none
For more information, see How to suppress code analysis warnings.
Example
The following code shows an event-handling method that can be misused by malicious code.
public class HandleEvents
{
// Due to the access level and signature, a malicious caller could
// add this method to system-triggered events where all code in the call
// stack has the demanded permission.
// Also, the demand might be canceled by an asserted permission.
[SecurityPermissionAttribute(SecurityAction.Demand, UnmanagedCode = true)]
// Violates rule: ReviewVisibleEventHandlers.
public static void SomeActionHappened(Object sender, EventArgs e)
{
Console.WriteLine("Do something dangerous from unmanaged code.");
}
}
