Security for Canadian Developers : ASP.NET 2.0

8 Simple Rules For Developing More Secure Code

jldavid — Mon, 28 May 2007 18:30:00 GMT

While surfing the Web, I came across the following article written by Michael Howard. The article really resonated for me because it covered the following points:

Using analysis tools and experts to review your code (which can be accomplished with tools such as FxCop, AppVerifier and PREfast)
Reducing risk using fuzzing and threat modeling (the ACE team has written a great threat modeling tool that I demoed at the Toronto ISC2 conference recently)
Keeping bad input out of your applications
Learning all you can about security concepts

It's a good read. Check out the article here:
http://msdn.microsoft.com/msdnmag/issues/06/11/SecureHabits/default.aspx

Are you interested in writing a post on this blog? Contact me here and I'd be glad to review and put up your security oriented article. Cheers!

ASP.NET AJAX Security Webcast

jldavid — Mon, 09 Apr 2007 20:45:00 GMT

Be sure to check out our latest security webcast this Wednesday. Here is the abstract: ASP.NET AJAX is a powerful framework for creating interactive and highly-personalized Web experiences that work across all the most popular browsers. Like any other frameworks, there are security considerations you need to take into account. In this session, you will learn the core security concepts and principles surrounding the ASP.NET AJAX framework and learn how to implement them in your existing applications.

Here is the link to register for the webcast:
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032329023&EventCategory=4&culture=en-CA&CountryCode=CA

Hope to see you there!

IIS 6.0 and ASP.NET 2.0 Credentials--Part Two

dansellers — Fri, 25 Aug 2006 07:30:27 GMT

The ASP.NET User Principal (HTTPContext.User) clearly depends upon the Authentication Mechanism that you selected in IIS 6.0 "Authenication Tab" and if you use Integrated Windows Authentication then it is dependant on the IIS impersonation token that get handed off in the extension control block via the ASP.NET 2.0 ISAPI API.

With ASP.NET 2.0 it is always possible to get the credential of the logged on user--hence the IIS impersonate token stored in the extension control block--even with Forms Authentication by using the Request.LogonUserIdentity. This was extremely difficult to do under ASP.NET 1.1.

So how does the IPrincipal object then get set in ASP.NET 2.0? If you are using Windows Authentication then one of two things occur inside of ASP.NET 2.0. It either takes the impersonation token and wraps it in the WindowsPrincipal object. Now a .NET Developer can do the standard User.IsInRole checks from inside your code-behind pages. However, if you allow Anonymous access inside IIS, ASP.NET detects this and ignores the impersonation token and ASP.NET puts in the Windows Anonymous identity instead. There is a boolean property on WindowsIdentity that tells you whether this token is anonymous or not.

Now what get interesting is when you use Windows Authentication and your Web Application will be acessing the File System. In this case IIS always uses the FileAuthorizationModule and as a result the FileAuthorizationModule always uses the IIS imperonation token and ignores the WindowsPrincipal on the context.

For example if you are using "Client Impersonation" the OS thread calls into ASP.NET 2.0 runtime and the "Set Client Token" API is fired and the IIS impersonation token is passed to the Windows Authentication Module and you can do checks against NT Security Groups. However, if you have anonymous enbled in IIS then the IIS Machine Account or Anonymous User will be swapped instead. Now as the request continues it will hit the FileAuthorizationModule, however, regardless of all the work that has been done up to this point the FileAuthorizationModule will do an access check using the IIS impersonation token, thus completely ignores what is set on the OS thread or the User Property as it always goes back out to IIS and finds out what the impersonation token is.

To test this you can create a sample webpage. This simple webpage will identity four parts:

The User identity's name on the HTTPContext,
The OS thread identity--by default NT Authority\Network Service,
Whether WindowsIdentity is Anonymous or not,
The User identity from the impersonation token.

The code would look similar to this in the page_load event:
{

lblHttpContext.Text += "'" + User.Identity.Name + "'"
lblOSThread.Text += WindowsIdentity.GetCurrent().Name;
lblIsAnonymous+=((WIndowsIdentity)User.Identity).IsAnonymous;
lblFromToken += Request.LogonUserIdentity.Name;--this allows to get back to Impersonation token

}

So as you will see we can have three different identities in ASP.NET.

To test out the behaviour of the FileAuthorizationModule you can modify the permission on the folder that contains your webpage and place an explicit deny permission on the "Internet Guest Account". On the "Authorization Tab" in IIS 6.0 clear the check box for "Windows Integrated Security" which will force the applicaiton to run as Anonymous User. Now when you try to run the Webpage, you will receive an Access Denied error, however, this error comes from ASP.NET 2.0 runtime and not from IIS which is the result of FileAuthorizationModule failing authorzation and the authorization check was done against the IUSER Account. Therefore, if you are using Anonymous user then the IUSER Account will have to be given permission at least read permission on your webpages.

For the second test go back to the "Authentication Tab" and enable the "Windows Integrated Security" and when you refresh the page you will now see the results of the webpage and you will notice the impersonate token and the HttpContext are now in sync. The OS thread will still be the Network Service Account and Anonymous WindowsIdentity will be false.

Therefore, you will not need to enable impersonalization for File Authentication to work as clearly behind the scene we have proven that the FileAuthenticationModule is using the impersonate token value contained in the extension control block.

So why would you turn impersonate on then? Because you need to flow identity off the box and you have delegation setup, or if you use an Authentication such as Basic which will give you one hop. Finally you might have an application that uses the File Object in your ASP.NET 2.0 code to perform some kind of File IO. Now if you set <identity impersonate="true"/> in your web.config and refresh the webpage you will now see that OS thread, HttpContext, and the IIS impersonate token are now all in sync.

On a final note this should reveal that the identity of OS thread alone is not going to provide you with some kind of silver bullet security to your WebApplication. I do not like the idea of changing the Network Service account which is already a very low privilege account for a domain account and think my Web Application will be more secure. First the Nework Service is already one of the lowest privilege accounts on WIndows 2003 where as the domain account will be a interactive account with a password, thus actually is has higher privilege. In fact it increases the attack surface and is now subject to account and password management.

Therefore, security is dependent upon the OS thread, the HTTPContext the trust level of your ASP.NET 2.0 Web Application as well as the way in which your application is configured. Finally, most importantly the input validation you put in your server side code. There is no silver bullet but rather defence in depth using a wide variety of mechanism.

If someone tells you something is 100% secure don't believe it as there is no such thing as perfect in this world. Do not look for the silver bullet for security as it does not exist. Would you do banking at a bank that uses the simpliest security mechanism to save your identity and money, probably not. So why go with the simpliest solution and think it will give you the highest level of security.

IIS 6.0 and ASP.NET 2.0 Credentials

dansellers — Thu, 24 Aug 2006 21:27:00 GMT

The one area that many developers do not have good grasp at is how Authentication tokens from IIS 6.0 is passed to ASP.NET 2.0 and how these tokens can subsequently be used for Authorization in an ASP.NET 2.0 Web Application.

The one question that arises quite often is when I click on “Integrated Windows Authentication” in IIS 6.0 “Authentication tab” how does this information get passed to ASP.NET 2.0 and when it is passed to my Web Application how do I flow the client identity between different Services such as a Web Service or a database like SQL Server for example?

On a side note if you need this client identity to flow across multiple hops between all your application servers, then you will need to use Kerberos with delegation credentials. A good article on how to configure delegation credentials is located here. If you are using Windows Server 2003 then two new features were added known as constraint delegation and protocol transition. With protocol transition, you could use form authentication on an ASP.NET 2.0 Web Application--as not to flow the Windows Authentication tokens across the Internet. In your ASP.NET code you can have Windows 2003 literally newop a new Windows Identity by calling impersonate based upon a user identity and string passed into the construct of WindowsImpersonate class and then enable impersonation on this new Windows Identity. This is new extension to Kerberos and allows you to flow this token off the Web Server to other Application Servers on your Network. Now of course for this to work your Windows 2003 Web Server needs to be part of a Windows 2003 Domain. The next thing you should also do is to enable constraint delegation. This way when use protocol transition to newop a new Windows Identity you can constrain this new delegated token so it can only talk to this particular SQL Server and a particular App Server for example. Thus, not allowing it to delegated to all service in your network which significantly increases the attack service.

So what pieces of identity information does IIS knows about based upon the configuration setup in IIS 6.0?

While the first IIS 6.0 knows of is the OS thread identity. This is the worker process that has an identity associated with it and has been configured in the IIS 6.0 Application pool on the “Identity tab” --which by default is the Network Service Account.

The second piece of identity information that IIS knows about is based upon the settings you configure in the “Authentication Tab” under IIS 6.0 such as “Integrated Windows Authentication”. In this example, IIS 6.0 will make the identity of calling user available after receiving the information when the browser negotiates with IIS 6.0.

Ok, so how does this relate to ASP.NET 2.0 and how are these two identities get passed to your ASP.Net 2.0 Application?

IIS 6.0 makes these tokens available via ISAPI extension and part of the APS.Net 2.0 runtime is an ISAPI API. Therefore, by default when your application starts up the worker process is spun up. Now of the course IIS 6.0 and ASP.NET will know about the worker process which is commonly referred to as the OS thread identity (by default Network Service Account). When the worker process calls your ASP.NET 2.0 the ISAPI API contains an extension control block. This extension control block will store a security token a.k.a the Impersonation token from the “Authentication Tab” that you configured in IIS, so for example if you enabled Integrated Windows Authentication then the Windows Authentication token of the logged in user as negotiated between IE and IIS is now passed to your ASP.Net 2.0 application.

So to recap what do we see from inside the ASP.NET side of the house?

One thing is we know the OS thread transitions over to ASP.Net with an identity on it from the worker process. This token value is available to make integrated resource type of calls. For example, if in my connection string I used integration security with SQL Server then it is the OS thread identity that is making the call regardless of who is logged into the ASP.NET application or the Windows Identity that may have been passed via the extension control block.

When we talk about impersonation inside ASP.NET we are talking about taking the OS thread and switching the identity to some new set of security credentials. The most common one is "Client Impersonation" in which the <identity impersonate=”true”/> tag in the Web.config is set and behind the scene when the worker process starts up ASP.NET 2.0 runtimes calls the “Set Thread Token” API which takes the impersonation token stored in the extension control block and now swaps it on top of the OS thread. Now the OS thread will now be running under the identity of calling user.

The other option is “Application impersonation” in which the “Logon User API” is called and takes the username and password as specified in the <identity impersonate=”true” user=”someuser” password=”somepassword”/> tag of our web.config. Now the OS thread will run under these credentials within the APS.Net 2.0 Application. With Application Impersonation this allows you run multiple applications in an single Application pool under the same executable but you want each application to use different identities when making resource calls.

In both of these instances the OS thread identity has been changed.

So far our ASP.NET 2.0 application knows about OS thread and the impersonation token from IIS, however, we cannot forget about the ASP.NET user principal which is derived from the HttpContext.User or Thread.Current Principal. In most cases the ASP.NET user principal and OS threat are not the same identity, thus we can have three different identities inside your ASP.NET 2.0 Applications.

In a big nut shell this is how the identity as specified under the Application pool “Identity tab” can be used to make integrated security calls under a single context or how this identity be swapped out with “Client” or “Application” impersonation depending upon our applications requirements.

In part two of this blog I will talk more about the ASP.NET user principal inside ASP.NET 2.0 and what we can do with this information.