Polymorphism and the potential security issues

Question

I just read an article on MSDN about reasons for declaring classes as sealed. In the last paragraph, Eric Lippert says:

4) Secure. the whole point of polymorphism is that you can pass around objects that look like Animals but are in fact Giraffes. There are potential security issues here.

I tried to look on the Google about this topic, but I didn't manage to find anything other that OOP tutorials, so if anybody could point me in the right direction where to look, or even say a few words on this topic, it would be great.

Thanks.

Answer 1

In terms of class/member access I would say "security" is more about API security. When you publish code that is fairly open, others may end up using your code in ways you did not intend, that make it harder for you to make internal, non-breaking changes in the future.

While some of the choices you make in OOP class/member access may influence your overall system security from external attacks, those choices are not strongly related to security from those type of attacks. Once you are already sharing program execution space, in most cases the other program can really do almost anything it wants to do, in some way or other. (For example, private members in Java can be accessed through reflection quite easily via setAccessible.)

When developing APIs, those kind of hacks are never supported by the library author, so they are "use at your own risk". With a good field/class access strategy, APIs can be refactored extensively with few external API breakages.

---

I tracked down the article that you are referring to, and the context helps illuminate this issue.

Point three is actually related to my original answer above:

3. Compatible. If in the future I discover that I should have sealed a class, I'm stuck. Sealing a class is a breaking change. If I discover that I should have left a class unsealed, unsealing in a future version is a non-breaking change. Sealing classes helps maintain compatibility.

The next bullet point is your original quote:

4. Secure. the whole point of polymorphism is that you can pass around objects that look like Animals but are in fact Giraffes. There are potential security issues here.

Following on helps illuminate the problems that Eric is referring to:

Every time you implement a method which takes an instance of an unsealed type, you MUST write that method to be robust in the face of potentially hostile instances of that type. You cannot rely upon any invariants which you know to be true of YOUR implementations, because some hostile web page might subclass your implementation, override the virtual methods to do stuff that messes up your logic, and passes it in. Every time I seal a class, I can write methods that use that class with the confidence that I know what that class does.

In this case, Eric is clearly referring to cases when a potentially hostile system is actually able to interact with your system with code. In that case, polymorphism does become an issue, since, as Eric says, when you make calls on the objects that are passed in, the object could be doing something you completely didn't intend it to do.

Sealing classes means that the object that is passed in cannot be subclassed in that way. Obviously there would be no need for this if your system is never going to interact with potentially hostile API callers. As my original answer said — often that is such a difficult security risk to manage in and of itself that is simply disallowed altogether.

Answer 2

Let's say you create a security validation class, which is passed to your main form by an IoC. Because you use this structure for a few different systems, like a good little programmer you create a base class with most of the logic, and put system-specific code in the derived classes.

An attacker takes a look, and finds this Template Method pattern. He also sees that a key piece of the puzzle, a property "SecurityDBConnString", is abstract (because it's used by base class logic but can't be specified there as it's system-specific), and when you overrode it for the system he's interested in, you didn't seal it. The attacker fires up his cracked VS copy, derives his own class from yours, further overriding SecurityDBConnString to point to a system he controls, then modifies the IoC registrations to pass in his new class. Now he's in, and you're in trouble.

This would all have been much harder had you simply sealed your derived class or the overridden property within it. It would be harder still if you'd obfuscated your security library, but I digress; if you do not want anyone to derive your class, seal it. You will save yourself many headaches.