Question

I’m developing a class library and I need to provide a way to set configuration parameters. I can create a configuration section or I can expose static properties. My concern about static properties is security. What prevents a malicious component from making changes at runtime? For instance, in ASP.NET MVC you configure routes using a static property. Is this secure? Can a malicious component add/remove routes?

---

How would the “untrusted component” get in my application in the first place? NuGet for example. We don’t know what’s out there, who did it, and if it contains small bits of undesired state changes.

How would the “untrusted component” run? In ASP.NET all you need is PreApplicationStartMethodAttribute to run some code when the application is starting.

Answer 1

When you consider something as a security threat, you should also think about from whom you are trying to protect.

In order for “malicious code” to alter the values of your static properties, this code would need to be loaded into your AppDomain and run. Now think that a malicious attacker has managed to get his code to run in your AppDomain – are your static properties really your major concern? Such an attacker can probably do a lot worst.

Unless you have a scenario where you need to load an assembly/code originating from external untrusted sources, I think you don’t really need to defend against your user accessing your properties (Not from security perspective anyway – usability is another thing).

EDIT – about external untrusted code

I still think this is not really your concern. If I understand correctly, you are developing and providing a library, to be used by some 3rd party in their application.

If the application owner decided to take some external library which he does not trust, add it to his application, and allow it to run, then this is not your concern, it is the application owner’s concern.

In this scenario, everything I said above still applies. The malicious code can do much worse then setting your properties. It can mess with memory, corrupt data, flood the thread pool, or even easily crash the AppDomain.

The point is, if you don’t own the application because you are only providing a class library, you don’t need to defend from code running inside the AppDomain where you classes are loaded.

Note: Re. NuGet, I wouldn’t be too worried about that. NuGet is sort of a static tool. If I understand correctly, it doesn’t do things in runtime such as downloading code and running it. It is only used in design time to download binaries, add references, and possibly add code. I think it’s perfectly reasonable to assume that an application owner that uses NuGet to download a package will do his due diligence to ensure that the package is safe. And he has to do it only once, during development.