Last week two security researchers, Thai Duong and Juliano Rizzo, have discovered a bug in the default encryption mechanism used to protect the cookies normally used to implement Forms Authentication in ASP.NET.

Using their tool (the Padding Oracle Exploit Tool or POET), they can repeatedly modify an ASP.NET Forms Authentication cookie encrypted using AES and, by examining the errors returned, determine the Machine Key used to encrypt the cookie. The process is claimed to be 100 percent reliable and takes between 30 and 50 minutes for any site.

Everyone immediately focused on the bug not mentioning what is commonly known as good practice and applied to every production site by any decent software developer “Never expose your production server errors (exceptions) to the client” failing to do so exposes your server to a number of threats not only the one described in the above security vulnerability.

There are several ways you could achieve that and Scott Gu mentions the easiest one in his blog post. An other way you could hide errors from your clients is by handling the Application_Error event in the web app’s Global.asax like this

void Application_Error(object sender, EventArgs e)
{
  try
  {
    Exception ex = Server.GetLastError();

                //Log any way you feel like

    Server.ClearError();
  }
  catch (Exception ex){	}
  finally
  {
    Response.Redirect("~/error.htm");
  }
}

Some of my colleagues are often reluctant to use ASP.NET 2.0 profile provider to store profile data for their web applications. The main reason for this is the fact that the default SqlProfileProvider that ships with ASP.NET 2.0 “blobicizes” Profile data using string, XML or binary serialization prior to storing information in SQL Server. This obviously puts a rather large overhead when you need to query your profile data.

What most developers aren’t aware though is that you can build your own custom profile provider to store Profile data “in the clear” in the database so that the data is available for querying and use in stored procedures.

As a matter of fact Microsoft provides an SqlTableProfileProvider sample implementation which stores each Profile property in a separate database column without serializing it, which means that the Profile property can be easily queried (of course the profile property type needs to be compatible with the target database column).

There is also a second sample provider, SqlStoredProcedureProfileProvider, which maps each Profile property to a parameter on a custom stored procedure. Like the table based provider, this provider expects that each Profile property is of a type that is compatible with its corresponding stored procedure parameter. The powerful aspect of the stored procedure based provider is that other than the requirement to implement some stored procedures with a specific set of parameters, you can implement whatever business logic you need in the stored procedures to map the Profile data to your own database schema and database logic.

You can learn more about these profile providers here.