6

We need to "protect" a class from having static methods for security purposes. We don't want newbie devs following suggestions of coding tools to make a member static as we need to use a constructor with a password to control access to this class.

Is there any way to protect a .NET class in C# to prevent it from have any static members?

Would such a feature, if not available, be worthwhile for a future version of .NET?

Thank you.

Neal
  • 9,487
  • 15
  • 58
  • 101
  • 10
    This seems like asking your tools to be responsible for the user. Why not just train your devs on how to use the API appropriately? – rossipedia Mar 27 '12 at 22:30
  • 2
    I'd really like to hear the reasoning to eliminate static methods. Can you share, please? – Wesley Long Mar 27 '12 at 22:31
  • 10
    Newbie devs vs. devs making constructors with passwords to restrict instantiation/inheritance? wow, and no its not a worthwhile feature – meandmycode Mar 27 '12 at 22:33
  • 5
    I would just like to point out that password protecting the constructor will not work in Full Trust scenarios since Reflection can just bypass that. Not sure if Medium Trust prevents private reflection. If you really, truly need to protect the implementation of the class, put it behind a service. – Michael Stum Mar 27 '12 at 22:36
  • 4
    If a class is critical to security, newbie devs have no business touching it in the first place. – millimoose Mar 27 '12 at 22:42
  • FYI folks, there's a reason and an architecture for many different scenarios. We have a project that is protected by strong naming validation, obfuscation, and a gateway defense of the password protected public constructor. We are taking all means to protect the project from being referenced or used by anything other than our calling projects. Yes, we monitor checkins, etc. - just asking if there was a way to prevent static members. For those that are mature - thank you, to the others, I pity you. – Neal Mar 27 '12 at 23:43
  • 1
    If you take pride in something, you will be offended by others doing it poorly, it isn't about maturity- additionally I don't buy the reasoning- the biggest take away you should have here is to try and realize the futility and senselessness of your efforts. – meandmycode Mar 28 '12 at 21:30

8 Answers8

28

we need to use a constructor with a password to control access to this class.

This sounds like a monumentally bad idea, but of course I know nothing about the security problem you're trying to solve. This is the far more interesting question than your question: What is the threat you are attempting to protect against? There is probably a better way to do it.

Is there any way to protect a .NET class in C# to prevent it from have any static members?

Have senior developers review the checkins of junior developers. Which you should be doing anyway, but particularly if the class has some kind of security semantics.

Would such a feature, if not available, be worthwhile for a future version of .NET?

That's unlikely in the extreme.

Thank you.

You're welcome!

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 2
    @SimpleCoder: My mother taught me to say that when someone thanks me. – Eric Lippert Mar 27 '12 at 23:07
  • @EricLippert: Then I would say you've made her proud :) – Chris Laplante Mar 27 '12 at 23:12
  • Eric, thank you for the reply. We want to prevent access to the project. We use strong naming validation, obfuscation, and the weak but effective password requirement for instancing. All methods of protecting use of this class library by anything other than our calling projects. – Neal Mar 27 '12 at 23:47
  • 4
    @Neal: "Access to the project" is not a threat. Suppose I told you "I want to prevent access to my house". OK, that's a sensible thing to want, but *what is the threat*? "I want to prevent access to my house because I'm afraid someone will steal my television" is very different from "I want to prevent access to my house because I'm afraid someone will put a bomb in the basement". The way you design a security system to mitigate those threats is different. – Eric Lippert Mar 28 '12 at 13:49
9

The easiest thing to do would be to set-up FxCop on your build server and write a custom FxCop rule to check for static members.

This question has details on how to write a custom FxCop rule.


Alternatively, as SimpleCoder pointed out, you can use StyleCop to enforce the rule on the source code.

This page describes how to set-up StyleCop with msbuild.

Community
  • 1
  • 1
Dan Rigby
  • 17,133
  • 6
  • 43
  • 60
8

You could probably use StyleCop to enforce a custom rule. It would have to be implemented as a build action, though.

Alternatively, you can use FxCop to analyze the binaries.

Chris Laplante
  • 29,338
  • 17
  • 103
  • 134
3

You can run a check using reflection at run time, but other than that, there is no language feature preventing static members.

I can think of no good use for such a feature. This is a problem of communication rather than one of implementation.

In your case, you could place your protected functionality in an abstract base class, and run a check to see if the user is authorized before performing any protected function.

Kyle Trauberman
  • 25,414
  • 13
  • 85
  • 121
0

I would think a sealed class would suffice, though static members are permitted in the original class declaration. I think derived classes would not allow further static members.

0

I have to admit I've never heard of such a security scheme. I think there's good reason why I haven't heard of it - are you sure it's as protective as you want it to be?

By requiring the constructor to contain a password, you're trying to protect yourself from people who use your class. But those people can decompile and recompile your class to remove the password check - so what are you protected against?

zmbq
  • 38,013
  • 14
  • 101
  • 171
0

Suggestions

  1. Training
  2. More Training
  3. Code Reviews
  4. Others suggested stylecop or fxcop - both good options
  5. If #4 fails - more training - this time tie it to performance reviews. :)
tsells
  • 2,751
  • 1
  • 18
  • 20
0

I pretty much agree with Eric Lippert. But in those cases I want to do something like this (sometimes just to stop myself to make mistakes) I try to write a unit test for it. Like this:

[Test]
public void Class_should_not_have_static_methods()
{
    var staticMethods = typeof (Foo).GetMethods().Where(x => x.IsStatic);

    Assert.That(staticMethods.Count(), Is.EqualTo(0), "Static methods: " + string.Join(", ", staticMethods.Select(x => x.Name)));
}
Allrameest
  • 4,364
  • 2
  • 34
  • 50