.Net Security: why public variables are a bad idea

Paladion
By Paladion

March 3, 2006

Public variables are bad practice  - I have always been told to stay clear of them. Why? Because they accept invalid values. Make those variables 'protected' or 'private', they told me. And then access them via get()/set() methods. Well, that was many years ago.

Turns out there’s also a good security reason why .Net developers should avoid public variables.

It's called Code Access Security (CAS). .Net relies on the CAS framework to enforce security across assemblies. When an inter-assembly call is made, .Net initiates a stack walk to check the permissions of the caller, and the callers above it in the call chain. This stack walk is fundamental to enforcing security in .Net. It ensures assemblies with less permissions cannot call privileged methods. [We discussed CAS and stack walks last month].

Notice the stack walk? Ay, there’s the rub. The stack walk is triggered only for function calls and not for public variables. Thus a public variable is not protected by CAS. So that’s one reason secure software should not use public variables. What about the get()/set() strategy? They work well with CAS - the stack walk checks if their caller has adequate permissions.

If you have reasons why public variables should be used, I'd love to hear that.


Tags: Uncategorized

About

Paladion

SUBSCRIBE TO OUR BLOG

Buyers-Guide-Collateral

WHITEPAPER

Buyer’s Guide to Managed Detection and Response

Download
MDR

Get AI Powered

Managed Detection and Response

MDR-learmore-btn

 

MDR-Guide-Collateral

REPORT

AI-Driven Managed Detection and Response

Download Report
Episode

EPISODE-25

Red-LineAsset-6

Why Your ‘Likes’ on Facebook May Be Revealing Far More than You Thought

Click URL in the Post for the Full Podacst
  • FacebookAsset
  • LinkedinAsset
  • TwitterAsset