PlaceHolder/Panel Visibility, ViewState on Security and Performance

It is not unusual to see a solution where use of asp:Placeholder and asp:Panel Visibility is employed to show/hide certain details from the user.

When implementing a simple Authorization/Permission features[more], it would also be tempting to use such approach. (mentioned simple since there are likely more complicated but better ways to do it) Of course you could always implement declarative authorization features in ASP.NET but I believe it would cause the user to be redirected to the page identified as the login url. (hmmm, does other authorization types support authorization rules? not sure myself, i wonder).

So if you simply perform checks in code.

eg. Does User.Indentity.Name have permission to view this page? Yes/No? If yes, display contents of panel/placeholder, if no set their visibility to false.

Simple and might do the trick.

BUT never forget that although they are invisible, some values might be present in the viewstate (eg. values bound to gridview inside the panel/placeholder). Although viewstate might look cryptic, remember that it is just base 64 encoded string. And although you could have employ encrypted ViewState, it would still be not a good idea and you will have unnecessary overhead.

So just a quick note to self (and possibly others) that settings PlaceHolder/Panel visibility to false doesn't stop it from saving information in viewstate. Obvious to some but not to all so if you're guilty, better fix that code before someone gets to see something they shouldn't.

I'm also interested how best to implement this in code (not using ASP.NET built-in declarative authorization rules – ie. in web.config). HttpModule maybe? But note that I would want the resulting page to have the same look and feel (still use master page) rather than simply a text in the page (and nothing more) or worst an exception throw because user doesn't have view permission for example, nor redirected to a generic page. I'll try to explore this but someone who might have a good idea out there comes across this and shares his/her notes.

UPDATE: Aside from the security consideration, note that disabling viewstate when not need could significant improve performance (dependent on how items you have in your page makes use of viewstate – eg. disabling view state when hiding a gridview is significant) so will be adding "Performance" to the title as well

Also, be cautious about disabling view state. It is used by control to
persist information across postbacks so if you do disable them make
sure you test your page well.



BlogEngine.NET version critical security patch

A security flaw was identified for BlogEngine.NET version and the team was quick enough to announce and release a patch.

Check the following link for details: Critical Security Patch Available [more]

It is unfortunate that the issue could not have been handled more
discretely.  If you are blogger writing about the issue, we'd hope that
you could refrain for spelling out exactly how to attack sites that
haven't been updated yet.  (Yes, we do want people to know there is a
problem that needs patched, but we'd prefer if were weren't tempting
casual hackers to try out the hack on a unpatched site by giving them a
step by step guide.)

Again, we are sorry for the inconvenience
and any trouble this may have caused you.  If you know of other
BlogEngine.NET users, please pass this information along.

For BE.NET users who have modified the BlogEngine.Core and would like to identify the changes without overwriting their customizations (and can't find details), I would suggest you look for an assembly diff tool to differentiate the patched and unpatched assemblies.

Encrypting configuration information in .NET (web/windows)

There are a number of articles on encrypting configuration information for ASP.NET (eg. an article by Scott Michelle (an authority in security)) using aspnet_regiis (pe or pef switches) or in code using DPAPI.

Although almost same principles apply, not much I believe is written for windows so since Job Galloway wrote a post recently on encrypting configuration information for a windows application I figured it's a good note to have and share. Let's make the digital world a safer place.


Link: Security Development Lifecycle (SDL) Guidance Download

For those not subscribed to Microsoft Security Bulletin, you might be interested to know that Microsoft just released their SDL Guidance (as of 4/9/2008 according to the download detail)

Security Development Lifecycle (SDL) Guidance Download Link [more]


As part of its commitment to a more secure and trustworthy computing ecosystem, Microsoft is making the details of the SDL process generally available online for the first time. IT policy makers and software development organizations can leverage this content to enhance and inform their own software security and privacy assurance programs.

It would be good to have everyone practice (have knowledge for a start) and we'd have a "little" safer digital world 😀

Minimum Permission Required for Assembly

A jumpstart on security your applications by determining and applying only the minimum required permissions. [more]

I ran into this thread on Resetting your web application or web site without recycling app pool or IIS. just recently. The basic idea of the first option for achieving its goal is to call "HttpRuntime.UnloadAppDomain();". Interestingly there's a note before that relevant code block:

// Method #1
// It requires high security permissions, so it may not
// work in your environment 

The other one is to set the LastWriteTimeUTC of the web.config (touching the web.config will trigger an appdomain unload/restart). Which in itself also requires some permission to modify web.config. 

Hmmm. So how will I know if it will work on my environment?

Looking around, I found this next How Do I…Request the permissions my code needs? BUT it actually only discusses how to "request" permissions that is needed by my (our) assembly. How do I know what I need to request in the first place?

Next stop, look for permissions the specific method ("UnloadAppDomain") requires? And where else but MSDN (or you can always google too). Now, as expected, you don't want just anyone restarting your site(s) over and over again so as pointed out there, this the method is decorated with this attribute : [SecurityPermissionAttribute(SecurityAction.Demand, ControlAppDomain = true)].

So the first way to determine minimum permissions is to review your code, determine what resources are accessed and operations are performed. Look for permissions required for those method and you're good.

However, if you have lots of calls and you need a startup point for determining your minimum permissions that's where PERMCALC.EXE (also goes by the name Minimum Grant Set Determination tool and Permission Calculator Tool (from MSDN) comes in. I ran into from How to: Use Code Access Security (CAS) in ASP.NET 2.0 in Channel9 (online). As in the link's title it also happens to be a good discussion for CAS in ASP.NET 2.0. CAS in general IMHO is trivial so ASP.NET had some ways of simplifying it for web applications. This link is a must-read so please feel free to leave this page for now and go read it before moving further.

Going back to AppDomain.Unload(), SecurityPermission with "ControlAppDomain" flag is actually something not available with minimal, low, medium nor high trust policy. So it's "almost" implied that you should run in FullTrust. But take note "almost", because I believe you can actually have a custom policy (say High trust with just the added SecurityPermission.Flags including AppDomainControl) rather than run your app in FullTrust when you don't really have to.

I must also mention that one weird thing I have noted is calling permcalc.exe -show <myassembly.exe or dll> and looking at the <sandbox> element returns different content than permcalc.exe -show -sandbox <myassembly.exe or dll>. For example running against a simple WindowsForms executable includes an IPermission that has Flags="UnmanagedCode" but having the -sandbox switch adds a new flag "Execution". I'll see what else I can find next time or maybe hopefully someone can clarify this. Along with the difference between <demand> and <sandbox>.

Another thing on the channel 9 link, it states that to configure trust level for your specific application you copy the web_CustomTrust.config to your application's vdir. But actually you can just leave it in the CONFIG folder of the framework and just set your trust level attribute in your application's web.config to the trustLevel name you assigned to the custom config file.

In the case of ASP.NET Web Site Projects (not to be confused with Web Application Projects) you would need to precompile your project to be able to use PERMCALC as you have read in one of the articlse above, it can only be run against assembly and not on ASPX pages directly.

Check out these links too:

  1. Channel9 Security How Tos
  2. Issues with PERMCALC
  3. Importing Permcalc Output into the .NET Framework Configuration Tool (Mscorcfg.msc) – it might be nice to have an app to perform this conversion automatically

I've always been intrigued with security but I'd have to say I have a
lot to learn about it so feel free to comment on this post if there's
anything I'm getting wrong or I'm missing, you simply want to drop by.

So there you have it, minimum permissions and making the world a safer place one thing at a time Laughing Now got to get back to work.

ZoneAlarm and localhost

Regardless of privacy settings, ZoneAlarm will always rejects cookies
when using localhost. Something that is not very developer friendly.

The work-around is to use instead.

you are using Visual Studio, you can set whether to use IIS and have
the starting url to use At least that how it works for
ASP.NET 2.0 Web Application Projects; there might be small differences
for Web Site Projects and older ASP.NET 1.1/VS2003; I couldn't verify
for other project types for now but just post to post on this issue.

Here's the thread where this information was taken from