Following the Wh1t3 Rabbit - Practical Enterprise Security

Enterprise Security organizations often find themselves caught between the ever-changing needs of the agile business, and the ever-present, ever-evolving threats to that business. At the same time – all too often we security professionals get caught up in “shiny object syndrome” which leads us to spend poorly, allocate resources unwisely, and generally de-couple from the organization we’re chartered to defend. Knowing how to defend begins with knowing what you’ll be defending, why it is worth defending, and who you’ll be defending from… and therein lies the trick. This blog takes the issue of enterprise security head-on, challenging outdated thinking and bringing a pragmatic, business-aligned, beyond the tools perspective … so follow the Wh1t3 Rabbit and remember that tools alone don’t solve problems, strategic thinkers are the key.

Rafal (Principal, Strategic Security Services)

Monday - Web Server Comedy

Security is a peculiar thing.  I've spent years telling people that there is such a thing as "good enough"... but sometimes I come across a situation where an attempt to be more secure makes an oops.  I found another one of these today so I wanted to point it out.

 As my browser hit this page I ran into the old " D'oh! " situation.  Clearly someone had taken the time to turn off remote-errors in the web.config file but hadn't taken the time to put a real custom-error page.  If you've ever run into this before I'll post the copy/paste of the page here ...

 

Server Error in '/' Application.



Runtime Error





Description: An
application error occurred on the server. The current custom error
settings for this application prevent the details of the application
error from being viewed remotely (for security reasons)
. It could,
however, be viewed by browsers running on the local server machine.



Details: To enable the
details of this specific error message to be viewable on remote
machines, please create a <customErrors> tag within a
"web.config" configuration file located in the root directory of the
current web application. This <customErrors> tag should then have
its "mode" attribute set to "Off".








<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>







Notes:
The current error page you are seeing can be replaced by a custom error
page by modifying the "defaultRedirect" attribute of the application's
<customErrors> configuration tag to point to a custom error page
URL.






<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>

 The first highlighted section is a good example of a best-practice on IIS servers.  Errors shouldn't be viewable by anyone outside your organization (or outside that server) because they can disclose sensitive information about your server, your web code, or other sensitive information.  I offer a congratulatory pat to the server admin for making that first leap to securing a web server.  Now for the disheartening part.  The defaultRedirect directive tells the server where to grab the page that is the "custom" error page (since it's not displaying detailed errors) but the admin overlooked that little bit.  While the security part of this "error" is taken care of unfortunately cosmetically it's still ugly.

Hey - no one said security had to be pretty, right?

Search
About the Author(s)
Follow Us
Twitter Stream


Community Announcements
HP Blog

Technical Support Services Blog

Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation