Your Stack Trace, Show It To Me
Of all the reasons you need an application delivery controller capable of bi-directional inspection of application data this is one of the best. I was trying to check out the results of a poll on PollDaddy.com and ended up with this beautiful Microsoft .NET error page, filled with so much valuable information that potential attackers must even now be laughing in that "evil genius" laugh you so often hear in retro-cartoons.
This error page tells me so many things about the application, it's environment, and its associated infrastructure that it should be a crime to let this information out. I know it's a Microsoft .NET C# application, and what the underlying directory structure looks like. I know it's using a third party library for authentication and authorization (and where it's located) and I can tell you exactly what version of .NET is running (Microsoft .NET Framework Version:2.0.50727.1433; ASP.NET Version:2.0.50727.1433).
I also get an idea of internal data structure, as a nice piece of code is included in the error page. Hmmm...looks like "user ids" are numeric in the database.
Now I'm no evil genius, so I can only imagine just how much this tells a real evil genius. I do know, however, that this simply an unacceptable security practice and that it should never happen. Ever.
We often discuss catching "errors", but that's usually wrapped around catching 404 (not found) errors. Using iRules you can easily catch 500 (Internal server errors) as well as any other HTTP status code.
And even if the status code somehow comes back as "200 OK" but the content is full of juicy application and infrastructure information, you can use iRules to deal with it. iRules can verify that the content of a page is what it should be and if isn't, you can do something about it. Rewrite it. Change it. Redirect the user to a new page. Show a page full of dancing bananas or a picture of a whale. Whatever you want.
The point is that you recognize when information that may lead to or assist in perpetrating a breach is being presented to users and that you prevent it from happening. The chances of the information being used against you is minimal, but when you have the opportunity to mitigate that risk entirely, why wouldn't you?
