Computers, Programming, Technology, Music, Literature

Posts Tagged ‘

Beefing Up Security In ASP.NET Part 2 Dot Net Bangalore 4th meet up on August 08 2015

leave a comment »





Written by gmaran23

August 10, 2015 at 7:14 pm

Beefing Up Security In ASP.NET Dot Net Bangalore 3rd meet up on May 16 2015

leave a comment »




Let your IIS worker process crash with StackOverflowException

with one comment


This article was originally published for and could be located at


Months back I posted a screenshot at, finally got time to write it down.


There was a Login page, that did some sort of authorization check beyond authenticating the user, and displayed an Access Denied page for those who weren’t lucky enough. This was all done by the ASP.NET MVC with ASPX view engine. So there’s things like Views, Partial Views, RenderPartial, and so on. The application also was heavily ajax enabled, so partial views really seemed to fit in at many places that did not want to include a master page content in the response text. There was a view file called AccessDenied.aspx that barked at unauthorized users. Things were working fine, and one day something broke, IIS was crashing without any meaningful error message. I lied, actually it did give a meaningful error message that was like – An unhandled exception of type ‘System.StackOverflowException’ occurred in mscorlib.dll. And the Call Stack showed some recursive function call. That is all there was to it.

Let’s look at a POC sample application below. Download the source from github –, Hit F5.




When you click the AccessDeniedForCrash page, the below is what you see. An unhandled exception of type ‘System.StackOverflowException’ occurred in mscorlib.dll. If you look at the Call Stack window, there would be a lot of repeated method calling method.




Let’s look at what happens when a view is requested, as in how the view engine probes the known locations to find the view definition. Click ViewDoesNotExist, and you would see an error page, that actually tells you the file locations that ASPX view engine probed to find a matching view. Pay attention to the search order where a .aspx file is searched first, and then the .ascx file.


Now, if you go back to the StackOverflowExceptionInASPXViewEngine solution, there are two files called AccessDeniedForCrash.ascx and AccessDeniedForCrash.aspx under ~/Views/Home.




The following code inside AccessDeniedForCrash.aspx calls the partial view AccessDeniedForCrash.ascx.


<asp:Content ID="Content3" ContentPlaceHolderID="FeaturedContent" runat="server">
            <section class="featured">
        <div class="content-wrapper">
            <hgroup class="title">
                <% Html.RenderPartial("AccessDeniedForCrash"); %>


A typical programming practice right? You define sub routines, and you keep calling them as and when required. Reusability! You have created a partial view here (AccessDeniedForCrash.ascx), and kept calling the partial view inside the main view (AccessDeniedForCrash.aspx). But it was the ASPX view engine’s probing method that caused the recursive method call. The view engine reached AccessDeniedForCrash.aspx, as it came through the HomeController’s action method AccessDeniedForCrash. It tried to find a partial view AccessDeniedForCrash.ascx,  but always ended up with AccessDeniedForCrash.aspx because of the file search order; you know the rest of the story about recursion without an exit condition.

So, is this a programming error? or the framework error? or the ‘programmer did not understand the framework well’ error?



You may also like –

Written by gmaran23

June 30, 2014 at 7:16 pm

How Forms Authentication implements a secure timeout on the cookie?

leave a comment »

It does not take a genius to alter the timeout on a cookie that is stored on the browser’s memory. Third party browser add-ins and developer tool bars or HTTP interceptors are easiest ways to begin with. ASP.Net’s Forms Authentication and it’s SetAuthCookie method handles the time out in a secure way. By secure way I mean the time out value of the cookie is actually embedded in the value of the cookie itself.

Now we all know that the authenticated user’s name is part of the AuthCookie value, but it is interesting to know that the time out for the session cookie is handled the same way too. And the normal rules of cookie value encryption and MAC verification apply.

Read through the entire blog –

A few important notes below:

Forms Authentication issues a cookie and embeds the username inside the cookie. Upon subsequent requests to the server Forms reads the cookie, validates it, extracts the username and assigns the username to User.Identity.Name (as well as Thread.CurrentPrincipal.Identity.Name).

To implement the cookie-based scheme securely Forms Authentication does several things:

1) Protects the cookie by encrypting and MACing it. This provides protection against people reading the cookie (including the user) and tampering with the value (including the user).

2) Provides a secure timeout on the cookie. Forms does not rely upon the normal cookie timeout — the user could easily change this. Instead Forms embeds the cookie timeout in the encrypted/MAC’d cookie value.

3) Sets the cookie as HTTP-only. This prevents client-side JavaScript from accessing the cookie (Session, to its credit, does this as well).

4) Allows the cookie to be marked as SSL-only. This, unfortunately, is not the default nor required (but I think it should for both… well, at least the default).

Written by gmaran23

March 27, 2013 at 10:22 pm