Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Security through obscurity...

I was talking with another developer recently about distributed web application architecture - security in particular. He told me about a classic ASP (3.0) web application he had done before. The entire web application consisted of one .asp file and several COM DLL's. The one .asp file had contents like this:

<%

   Set obj = Server.CreateObject(“MyLibrary.ClassName“)

   obj.ProcessRequest Request, Response, Application

%>

The COM DLL referenced the ASP 3.0 type library of course, and accepted the Request, Response and Application objects as parameters to the ProcessRequest method. I had never thought to do something like this.

He went on to explain how the data access components were part of a COM+ package that used impersonation to access the database using a trusted connection. To implement a session state, the only thing used was a GUID placed in a cookie. When pages required session-type information, the GUID from the cookie was used like an ID value to perform the necessary lookups.

The obvious benefits I could think of right away were:

  1. Huge performance gains. Say goodbye to script interpreting and hello to compiled code execution. Hmm...sounds kinda like ASP.NET doesn't it?
  2. No more dependency on ASP session state management.
  3. No database connection strings with a username or password, .. anywhere.
  4. If an intruder got access to your web server, all they get is an .asp file with 2 lines of script in it.
  5. Scalability - Since there is no dependency on ASP session state management, more hardware could be thrown at it.

The burdens to this I could think of are:

  1. Maintainability might become an issue. Even if you needed to change some HTML or CSS it would require recompiling. This might not be that much of an issue - I've had to do the same thing for some ASP.NET applications.
  2. Development time might increase for someone not used to building a web application this way.

Now, since the ASP.NET execution model does not include interpreting script, this takes away the performance gain. What I'm still thinking about though, is, is this really a viable security technique for an ASP.NET application?

2 Comments

  • I've actually worked on systems like this. They're completely insane! Why not worry about making your web-server secure rather than waste time and write code which is far more complex than it need be.



    Obviously with the advent of ASP.NET, this problem is solved much more nicely!

  • Pat,

    Thanks for that link to the Patterns &amp; Practices page. I must have missed that PDF - because I've downloaded and read just about all of them.

Comments have been disabled for this content.