.NET Security No No

OK. I’m going to cover this one time for guys in the peanut gallery.

Microsoft wised up some time ago and started shipping their Windows Server 2003 product with nearly every feature, apart from logging in, turned off. This was in response to the many-fold accussations that Microsoft was more concerned with functionality than security. (one could argue that they STILL are more concerned with features, but now consider security to be one of those features). In any case, today, when you install a Microsoft server product, it will have limited features, and this is a good thing.

What isn’t good is that developers and administrators keep bypassing this security by elevating priviledges for their code. They somehow feel that its appropriate to strong name their assemblies, and then grant full trust to any code with that strong name. This is an absolute NO NO!

Lets consider this scenario.If your house had priceless valuables stored in it, you would want the best security you could afford. You would remove the standard key/lock system, and replace it with biometric readers, voice print recognition systems, and panic button fail-safes. You might place further restrictions on rooms that contain your most prized possessions in case you have a dinner party — you wouldn’t want just anyone wandering into those rooms without your permission.

The same goes for your code. Think of permissions as the valuables to your code’s household. Grant permissions only when necessary, and only when all appropriate evidence has been supplied. Put fail-safes on your code by denying access to it by any callers that have elevated privileges. When clients access your application, don’t assume they should have access to all your code. If there are portions of your code that perform priviledged operations, require the client to provide additional evidence.

You need a layered approach to security. Granting Full Trust to your strong-named code will definitely help it run whatever you want it to, but you’ll also open the doors to anyone else that finds your valuable resources of interest.

Be Sociable, Share!

    One Thought on “.NET Security No No

    1. The same holds true for least priveledge. Developers take the high road: require admin access. Rather than only granting the least amount of permissions necessary they just make sure you can do anything, then wonder why people exploit their security to reak havoc on a system. I won’t deny that it’s a lot harder work and MS hasn’t made the job exactly easy but I think Longhorn should address much of this and hopefully force a least priveledge mindset on developers. Requiring admin access is like having biometric locks and voice print recognition systems yet hiding a key under the welcome mat. Once someone sees you hide that key, all of that security effectively means nothing.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Post Navigation