What are the security implications for accepting anonymous methods (Action <>, Func <>) as parameters?

Question

Just as the title reads: What, if any, are security implications that need to be considered when using and / or bypassing anonymous methods ( Action<> , Func<> ) in C #?

The method that accepts Action<> / Func<> seems to be a potential way to enter external code into a program. For the record, I understand that the introduced method or function cannot perform inherently unsafe things in the sense of random access to memory, but I think that it could allow the calling code to call, for example. arbitrary .Net infrastructure features, corrupted data, or other reasons why the application behaves badly.

Is this assumption wrong?

If this is not the case, what to do to block them? Also, is there a way to check / Func<> , which is passed to a method or function to ensure that it has the expected form or restricts its access to certain types and namespaces?

Also, forgive me if I do not quite use the correct terminology, I am still involved.

Answer 1

A method that takes action <> / Func <> seems to be a potential way to enter external code into a program

This is completely wrong. The one who calls your function and passes the delegate, by definition, already runs the code in your program.
Any code that passes a delegate can already do whatever it wants. You cannot have security boundaries inside the same AppDomain. (older versions of .Net had Code Access Security trying to do this, but that was not a good idea)

However, it can create unexpected reconnections, which can cause thread-safe code problems.

Answer 2

I really ask if scripts exist

Back when CAS was still in use (for example, medium trust ASP.NET), the trusted portion of the code could not safely invoke untrusted code if there were stack statements. For example, if

 new SecurityPermission(Unrestricted).Assert() 

in fact, the security check stack check stopped at that point. This may result in untrusted code not being detected. See docs for Assert.

I'm a little vague because the script is hard to shoot and it's out of date.

---

In the absence of a boundary of trust within the same process, the caller already has all the power even without entering the code somewhere. No need for this.