WebCast's Notes: Least Privilege and New System.Security Features

In today’s Webcast we first started off with a continuation from last week.  Last week we explored how to setup a development and design environment that closely emulates your production environment to make your testing more effective and efficient.  This was accomplished by enabling Debug in Zone and using tools such as permcalc.  This week we explored another complimentary practice to better emulate your production and testing environment by designing and developing an application with a least privilege account.  

 

In Visual Studio 2003 we needed to be a member of VS Developers to be to authorize Web Sites on the local computer or be a member of the Debugger User group to debug applications locally or remotely.  Thus, by belonging to these groups we are increasing our privilege level.  Therefore, in Visual Studio 2005 we have the ability to develop and debug application by only being a member of the built-in User group.  By developing as a least privilege user it ensures that we can avoid a lot of the common LUA bugs.  LUA bugs are introduced into your application when we develop and deploy an application which accesses resources that an End-User would normally not access if they only belong to the built-in User group.  This result in either rewriting a portion of the application or worse of all--which occurs all too often is to increase the privilege level of the End-User to ensure the application will function properly.  

 

Now of course developing under a least privilege account does expose certain challenging such as when you need to install software or make certain configuration changes that require administrative capabilities.

 

  1. We could use RunAs however as mention there are some limitation when using RunAs alone.  
  2. Fast User Swithcing is another awesome strategy but this feature is disabled when your Windows XP machine belongs to a Domain.  
  3. Under Windows 2003 logging in as a user to develop your application and having a remote desktop open as Administrators works very well as demoed today.  
  4. Now if you are not using Windows 2003 then on Windows XP MakeAsAdmin overcomes a lot of the challenges of RunAs.  

 

I recommend you review the following blogs:

 

 

In the second half of today’s WebCast we explored the use of SecureString.  SecureString has a lot of advantages over System.String for storing sensitive information--as mentioned in the Webcast--but unfortunately if you want to use it for something like password etc it does not come with any UI component.  As you can see from the bad login demo the clear text of password was still in the Text property of the TextBox control.  However, in the Good login demo I was able to rectify this by using a Custom Windows Control that was derived from the standard TextBox control.

 

  • The SecureTextBox control can be downloaded here.
  • Other SecureString demo can be downloaded here.

 

Finally we explored the Crypto API that allows us to encrypt a portion or an entire XML document following W3C standards.  In the demo I used a combination of both Asymmetric and Symmetric keys for both the encryption and signing a portion of the document.

 

  • The demo code from today application can be downloaded here:

 

And for today’s skill testing question:

 

The KeyInfo element can consist of either a <KeyName/> or a <RetrievalMethod/> child element.  What is the purpose of each element and what are the differences between the two elements?

 

Hint:   Cryptography.XML API follows the W3C standards which defines all elements in an encrypted XML document.

 

The first three people to email me the correct answer via this blog will have a chance to win a copy of the “Writing Secure Code Edition 2” book.