Skip to content

Latest commit

 

History

History
executable file
·
95 lines (75 loc) · 4.48 KB

SecuringErrorLogPages.md

File metadata and controls

executable file
·
95 lines (75 loc) · 4.48 KB
Raw
title layout permalink article
Securing Error Log Pages
page
a/securing-error-log-pages/
true

You can secure ELMAH's display or feeds in two ways:

  • Enabling or disabling remote access
  • Granting or denying access via ASP.NET authorization

Both of these are discussed in the sub-sections that follow.

Why is this so important?

See ASP.NET session hijacking with Google and ELMAH.

Enabling or Disabling Remote Access

ELMAH provides a configuration section and a setting to enable or disable remote access to the error log display and feeds. When disabled (the default), only local access to the error log display and feeds is allowed. The snippet below shows how to enable remote access:

{% highlight xml %}


{% endhighlight %}

Remote access is enabled when the value of the allowRemoteAccess attribute is either 1, yes, true or on. Otherwise it is disabled. Local access is always available.

Have expected configuration sections declared

Make sure you have declared the expected configuration sections in order to apply the above configuration. See Declaring configuration sections for more.

Granting or Denying Access via ASP.NET Authorization

If you must enable remote access, it is paramount that you also secure access to only authorized users. You can do this using ASP.NET's built-in authorization mechanism.

Different locations in a web site can be secured with different authorization rules. Suppose your web application is deployed at http://www.example.com/ and ELMAH is configured to respond to elmah.axd. You can secure http://www.example.com/elmah.axd from unauthorized users by adding a location element to your configuration as follows:

{% highlight xml %}
<system.web>

</system.web> <system.webServer> </system.webServer>
{% endhighlight %}

There are three important things to note here:

  1. The handler registrations need to be moved under the location tag. Having them outside does not secure access sufficiently.
  2. The location element's path attribute carries the same value as the path attribute of the handler registrations. Unfortunately, it has to be repeated so if you change one, the others must be updated to match.
  3. The authorization element is where the authorization rules go and where you will want to selectively grant access.

The configuration example above denies access to all users, but that is a good starting point. You will probably want to add rules that allow access to only specific users and/or roles. For example, you might have a role for administrators and developers called admin and dev, respectively. To allow users that are members of either role, you could configure the authorization section above as follows:

{% highlight xml %}




{% endhighlight %}

Further Information

For more information, see also: