1

I noticed some HTTP Handlers in my Web.config that appear to intercept HTTP traffic and manipulate it.

Since there has already been an exploit with a similar component produced by Microsoft, what should be done with *.AXD's produced in-house and 3rd parties?

Should I treat servers with custom AXD's differently than other web servers (such as creating a high security VLAN?)

makerofthings7
  • 50,090
  • 54
  • 250
  • 536

2 Answers2

3

HttpModules are application-level code. They are enabled for an application in its web.config and should not (accidentally) affect other application pools. They don't inherently have any more rights than any other app code.

Consequently they deserve the same level of auditing as any other custom code you're running, but don't bring in any risks to the infrastructure that you don't already have.

bobince
  • 12,494
  • 1
  • 26
  • 42
3

HttpModules != HttpHandlers.

A HttpModule runs in the pipeline before any page loads. A page is a special HttpHandler. A HttpHandler runs custom code for a particular file extension without having to load the WebForm Page object (unless its the aspx HttpHandler). The difference between using either of these compared to sticking code into a page is when the code executes within the lifecycle of the request. @Bobince has it right. They are application-level code so they cannot breach another application pool any more than page-level code can.

The real question is: Should custom applications be on a seperate VLAN? Ehh... depends on the environment you need to protect, the application itself, and the consumers of the application.

Steve
  • 15,155
  • 3
  • 37
  • 66