- Problem Domain
- .NET Hook to HTTP Pipe
- Implementing the IHttpModule Interface
- Building and Configuring IHttpModule
- Quick Testing of Deployment
- More Security with StateWall
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Implementing the IHttpModule Interface
To implement IHttpModule in HTTP pipe, create library code as shown in Exhibit 1. Create a namespace called StateWall with a class called StateShield, extended by IHttpModule. Ensure that the System.Web and System.Web.SessionState libraries are added, as shown below:
using System.Web;
using System.Web.SessionState;
namespace StateWall
{
public class StateShield : IHttpModule
{
public void Init(HttpApplication ctx)
IHttpModule has an Init method that provides a handler to HttpApplication, as shown in Figure 2.
)
Figure 2 Object view of IHttpModule.
Once a handler to HttpApplication is obtained, each incoming request can be processed at different stages of events. HttpApplication provides access to several events. Of particular here interest is the PreRequestHandlerExecute event that must be captured to process filtering rules. Figure 3 illustrates an object view of HttpApplication.
)
Figure 3 Object view for HttpApplication.
Begin by setting up a hook in the pipe for a PreRequestHandlerExecute event and access the context for the HTTP request. This context gives access to three important objects—Request, Response, and Session. The Request object allows us to determine the Web application resource that the HTTP request is attempting to access, along with other variables defined in the HTTP header. The session cookie can be accessed from the HTTP request, and in-memory session variables can be captured from the application. This will help execute a session-based rule set. The Response object provides a stream handler to the end client to send back a message to the browser. The following lines would provide a reference to the current context:
public void Init(HttpApplication ctx)
{
ctx.PreRequestHandlerExecute += new EventHandler(RunSessionRules);
}
The preceding code captures the event and passes it to the function RunSessionRules. At this point, each incoming request will be processed by this customized function prior to hitting internal ASP.NET resources.
The next step is to process a session-based rule set. Let’s take a web application example to understand this concept clearly.
We have a sample application running at http://login.example.com. We want to ensure that all ASP.NET key application resources on this web site can only be accessed by authenticated users. Authentication is on the login.aspx page.
We are also interested in having a logout.aspx dummy page to clean up inactive sessions. Developers often forget to implement proper session variable cleaning up routines. This task can be done by StateWall itself.
The site has different application modules such as blog, mails, and profile. Once credentials have been authenticated, the application adds a session variable called login and assigns it the value successful. Therefore, an established session is a must in order to access web pages other than login.aspx. Here is a state-based rule set for this scenario:
<allow "login.aspx"> <allow if session="login" & value="successful"> <clean session "logout.aspx">
This is a very simple rule set, and to maintain programming clarity, StateWall includes static values in the code. However, file parsing for XML files can be built dynamically. At the same time, session-based logging can be added as well, which can be meaningful in many cases.
Here is the code for obtaining a handler to the current session and context:
private void RunSessionRules(object sender, EventArgs e)
{
HttpContext ctx = HttpContext.Current;
HttpSessionState session = ctx.Session;
HttpContext is taken from the current context to build the HttpSessionState object from the context's session. This will provide access to all session variables. Session states can then be inspected in the application memory space.
For all requests for the logout.aspx page, a clean-up routine is invoked to remove respective sessions from the application space. Even if a cookie is replayed after logout, no traces of that session exist on the server, and the user is redirected to the login.aspx page. Here is the code to clean up session information from the application space:
if (ctx.Request.Url.LocalPath == "/logout.aspx")
{
session.RemoveAll();
ctx.Response.Write("All session variables are flushed out!");
ctx.Response.End();
}
For all requests for login.aspx, nothing is done other than redirecting the user to the authentication page. However, requests for any other page will require some processing to be done as shown below:
if (ctx.Request.Url.LocalPath != "/login.aspx")
{
int flag = 0;
foreach (string key in session.Keys)
{
if (key.ToString() == "login")
{
if (session[key].ToString() == "successful")
{
flag = 1;
}
}
}
if (flag == 0)
{
ctx.Response.Write("Unauthorized access without session.");
ctx.Response.End();
}
}
The preceding code grabs all session keys or name-value pairs created in memory using the session object, and runs them in a loop. Then the variable login is inspected for the value successful contained in all keys. If there are no matches, simply set a flag, send a response with the string Unauthorized, and stop the communication. If a match occurs—meaning, if session information is found on the server—access is provided to the resource requested for by the client.
With this defense in place, the entire application has been protected without a single line of code for session variable checks being written anywhere in the application. There is no burden on developers to make a correct session check.