Most efficient way to terminate an ASPX web request.

views:

answers:

+1 Q:

Most efficient way to terminate an ASPX web request.

I am writing some application logic which can recognize malformed or malicious http post data requests made to an IIS 5 aspx page. What is the most efficient way to terminate a bad request?

At the point where a bad request is identified there will be no buffered output and the C# function exit stack is shallow.

My hunch at the moment is that the additional turmoil of response.End() together with its thread terminate exception, might be more disruptive in a DOS attack situation than a regular 204 "no content" response.

To put some perspective on what my site is doing, all aspx hits result in DB query activity of say 10ms to 300ms, so responding to a malformed request as a regular 204 reply in 0.5ms represents a large saving.

I would make a custom IHttpModule and have it pre-process all aspx (or any other filetypes you want).

If your not familiar with IHttpModule they contain methods like OnBeginRequest OnError etc. You register them in your web.config file. You can easily have a custom ones that runs at the very begining of the request and have it look for naughty bits.

http://msdn.microsoft.com/en-us/library/ms227673.aspx

ryber 2009-09-08 12:36:19

Ok, interesting I thought plumbing in a C# IIS request pipeline handler was something new in II7. (I am stuck with Windows 2003 on an Amazon EC2 VM instance). Anyhow I can see the advantage of a common interception security point but this still leaves the question about how to terminate a bad request efficiently? Request.Close() zaps the underlying socket.

2009-09-08 12:47:56

If you concerned with the overhead of close then just redirect the request to a dead-end static html page.

ryber 2009-09-08 18:17:40

@ryber "just redirect the request to a dead-end static html page". Ooo no, response.Redirect() triggers an exception which is the last thing I want to do during a suspect DOS attack.

2009-09-08 18:49:46

What exception? According to the documentation it only throws a HttpException if the headers had already been sent. If it's being called from a IHttpModule before the rest of your app gets a hold of the request then it should be perfectly fine.

ryber 2009-09-08 20:45:37

@ryber Thanks for the clarification. I was referring to thread abort exceptions which can cause IIS to wobble when thrown at high frequency. But good news if these do not trigger from an IHttpModule.

2009-09-09 01:19:04

ansaurus

tags:

views:

answers:

Most efficient way to terminate an ASPX web request.

related questions