errorFilter does not work in Medium trust configuration (SecurityException - "Request for the permission of type 'System.Security.Permissions.ReflectionPermission...' failed")

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create an ASP.NET Web Application and configure both ErrorLogModule and 
ErrorMailModule in Web.config.
2. Try to hack the website using something like "/?<script>" (to throw an 
HttpRequestValidationException).
3. Verify the error is logged as expected and an email is received from ELMAH.
4. Specify the following filter in Web.config:

  <elmah>
    ...
    <errorFilter>
      <test>
        <!-- Do not send email notification when hackers attempt something like "http://.../?<script>" -->
        <and>
          <equal binding="FilterSourceType.Name" value="ErrorMailModule" type="String" />
          <is-type binding="BaseException"
            type="System.Web.HttpRequestValidationException, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
        </and>
      </test>
    </errorFilter>
  </elmah>

5. Repeat step 2.
6. Verify the error is logged as expected but the email is *not* received (so 
far, so good).
7. Change the website to run in Medium trust:

  <system.web>
    <trust level="Medium" originUrl=".*" />
    ...
  </system.web>

8. Debug the website and set the debugger to break on all exceptions.
9. Repeat step 2.
10. Observe the following exception (in DataBinder.Eval method, line 59):

System.Security.SecurityException ("Request for the permission of type 
'System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.")

What is the expected output? What do you see instead?

The filter should work in Medium trust (meaning the error should be logged, but 
an email should not be sent from ELMAH due to the filter). Instead of correctly 
applying the filter in the Medium trust configuration, a SecurityException is 
thrown and the error is not logged at all (even by the ErrorLogModule).

What version of the product are you using? On what operating system?

I have verified this issue occurs in the latest released version of ELMAH (1.2 
SP1) as well as the latest rev (a53a22fcf694 - 2.0.11227.2305).

OS = Windows Server 2008 R2 SP1

Please provide any additional information below.

I will attach a repro solution in a moment (as soon as I have an issue #).

Original issue reported on code.google.com by jjame...@technologytoolbox.com on 26 Feb 2012 at 10:21

[GoogleCodeExporter]

Attaching repro solution

Original comment by jjame...@technologytoolbox.com on 26 Feb 2012 at 10:30

Attachments:

• Elmah.ReproIssue277.zip

[GoogleCodeExporter]

The problem here is with FilterType.Name which is exactly the same issue you 
are experiencing in #278.

Merged into #278 as it contains a slightly better summary!

Original comment by jamesdriscoll71 on 27 Feb 2012 at 2:23

• Changed state: Duplicate

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I don't agree that 277 is a duplicate of 278. These are two discreet issues. Am 
I missing something?

Original comment by jjame...@technologytoolbox.com on 27 Feb 2012 at 3:43

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Perhaps I'm the one missing something!
Both issues seem to me to be caused by FilterType.Name

Original comment by jamesdriscoll71 on 27 Feb 2012 at 5:27

[GoogleCodeExporter]

I wouldn't say they are *caused* by FilterSourceType.Name, but rather they
are reproducible when trying to use FilterSourceType.Name.

Issue 278 refers to the fact that the JScriptAssertion class behaves
differently in Full trust and Medium trust -- due to (what seems to me to
be) a caching issue.

In other words, I discovered issue 277 first -- because you can't use
DataBinding to access FilterSourceType.Name when running in Medium trust.
Consequently I switched to using a JavaScript filter instead (since my site
*must* run in Medium trust in the hosted Production environment). However,
that's when I discovered that using JScriptAssertion works as I expect in
Medium trust (meaning the unwanted email messages are *not* sent) but does
not work as I expect in Full trust (meaning the unwanted email messages are
sent).

Jeremy

Original comment by jjame...@technologytoolbox.com on 27 Feb 2012 at 6:05

[GoogleCodeExporter]

This appears to be distinct from issue #278 and therefore needs to reviewed 
separately.

Original comment by azizatif on 27 Feb 2012 at 9:51

• Changed state: New

[GoogleCodeExporter]

Apologies for not getting the difference first time around.
I've just been thinking about a better resolution, and this is currently 
possible with the existing codebase instead of:

  <equal binding="FilterSourceType.Name" value="ErrorMailModule" type="String" />

use:

  <is-type binding="FilterSource" type="Elmah.ErrorMailModule"/>

NB FilterSourceType.Name still needs further investigation!

Original comment by jamesdriscoll71 on 28 Feb 2012 at 8:01

[GoogleCodeExporter]

This is not a problem with error filtering. The runtime is correctly raising a 
SecurityException due to limited permissions under Medium trust.

The binding attribute uses reflection to evaluate "FilterSourceType.Name". 
Normally, reflection on public members such as Type.Name (FilterSourceType 
yields the Type object describing the filter source object) is allowed, even 
under Mediuem trust[1], but there's a very subtle reason why SecurityException 
is still being thrown. At runtime, Type objects are actually implemented by a 
derived class called RuntimeType and which is not public. Invoking the *real* 
getter behind RuntimeType's implementation of the inherited Type.Name property 
causes a permission demand and fails. You can reproduce this problem without 
ELMAH by doing the following, for example, in an ASPX page:

<%= System.Web.UI.DataBinder.Eval(this.GetType(), "Name") %>

ELMAH also uses System.Web.UI.DataBinder.Eval internally[2].

As James has already pointed out, you can use the following as a workaround:

<is-type binding="FilterSource" 
    type="Elmah.ErrorMailModule" />

Alternatively, you can also write your own filtering assertions[3] that don't 
use reflection or incur permission checks.

While this issue is being closed as invalid (being external, by-design and 
having workarounds), Jeremy, I'd like to thank the detail with which you 
reported it. Not everyone goes through the trouble to provide a simple solution 
to reproduce the case and which helps to nail things quickly.

[1] http://msdn.microsoft.com/en-us/library/stfy7tfc.aspx
[2] 
http://elmah.googlecode.com/svn/tags/REL-1.2-SP1/src/Elmah/Assertions/DataBinder
.cs
[3] 
http://code.google.com/p/elmah/wiki/ErrorFiltering#Writing_Your_Own_Assertion 

Original comment by azizatif on 28 Feb 2012 at 8:14

• Changed state: Invalid

[GoogleCodeExporter]

Personally I'd much rather see the status designate something like "Won't Fix" 
(like we used to say back when I worked at Microsoft) rather than "Invalid" -- 
but I suppose this is more of a nitpick with the setup of 
http://code.google.com.

"Invalid" makes me think this isn't a bug -- and at the very least, I would 
really like to see some *Important* note on the ELMAH error filter page 
(http://code.google.com/p/elmah/wiki/ErrorFiltering) stating the known caveat 
when running in Medium trust.

Original comment by jjame...@technologytoolbox.com on 29 Feb 2012 at 2:48

[GoogleCodeExporter]

Frankly, I don't like "Invalid" either but it can be read many ways. The 
reading here is that the assumption that the defect lies with ELMAH is invalid. 
Something like "External" would be better for this particular case and a few 
others but I'm thinking YAGNI here. We rarely need to go back and make 
distinctions between closed issues. "Won't Fix" is usually used when there's a 
suggestion for a fix that may have a big impact (e.g. breaking change) on 
existing installations and where a reasonable workaround exists.

Would you be interested in formulating the *important* note or caveat on the 
ErrorFiltering wiki page? If yes, you can clone the wiki repo[1] and suggest 
the text. If not, I'll take note to add it at some point. Thanks!

[1] http://code.google.com/p/elmah/source/checkout?repo=wiki

Original comment by azizatif on 1 Mar 2012 at 9:37