Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
In terms of class/member access I would say it's more about API security. Others may end up using your code in certain ways that make it harder for you to make changes in the future. –  NickC Jul 12 '11 at 22:53
    
That does make sense, thanks. –  Nemanja Boric Jul 12 '11 at 22:57
    
I expanded my comment above into an answer. –  NickC Jul 12 '11 at 23:01
add comment

2 Answers

up vote 5 down vote accepted

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.

share|improve this answer
    
I didn't know about term API security, I thought that he was thinking about what is called security in general. I will go and read something more about it, thank you for the directions. –  Nemanja Boric Jul 12 '11 at 23:05
    
I should add that I can't guarantee that that's what was referred to, but I am instead speaking in general terms. –  NickC Jul 12 '11 at 23:06
1  
I actually expanded my answer after I found the original article. Updated now. –  NickC Jul 12 '11 at 23:16
1  
Developers use "for security reasons" the way politicians use "for the children". Early, often, and badly. –  Steven A. Lowe Jul 12 '11 at 23:59
1  
Security is the wrong term for this... perhaps correctness is closer to the original intent. After all its just a restatement of the open closed principle. –  CurtainDog Jul 13 '11 at 1:11
show 8 more comments

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.

share|improve this answer
    
But, how can base class can be sealed? Should not that make impossible to have my own derived classes (which I would write for specific platforms)? –  Nemanja Boric Jul 12 '11 at 23:17
1  
The base class may not be able to be sealed, but it may have an internal constructor that can't be referenced by a derived class in another assembly, or it may have other features designed to make sure it is only derived by "in" people. When deriving it, you fulfill those security requirements, but by not sealing the derived class, your attacker can now piggyback on your object's good name to do bad things. That was the point. –  KeithS Jul 12 '11 at 23:31
    
Yes, I see the point. Thanks for the good answer! –  Nemanja Boric Jul 12 '11 at 23:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.