Home Dashboard Directory Help
Search

WCF IErrorHandler logging SecurityExceptions by CrazyLegsFitz


Status: 

Closed
 as Fixed Help for as Fixed


6
0
Sign in
to vote
Type: Suggestion
ID: 371181
Opened: 9/30/2008 4:52:57 AM
Access Restriction: Public
0
Workaround(s)
view

Description

The WCF IErrorHandler.HandleError method does not record an accurate stacktrace when a SecurityException is thrown.
Details
Sign in to post a comment.
Posted by Microsoft on 6/15/2009 at 9:41 AM
Sorry, I should have been more specific. Because SecurityException is a CAS exception, it has to be special-cased within WCF. WCF supports a very limited set of scenarios in Partial Trust, so we had to be very careful in how we handle SecurityExceptions in order to ensure that service authors weren't susceptible to simple Denial of Service attacks (i.e. an unhandled SecurityException crashing the process).

Instead of seeing a SecurityException in your IErrorHandler, you should see a FaultException with "Access is denied" as the Message. I thought that this behavior may have been introduced in WCF 3.5 when Partial Trust support was added, but it is in fact consistent with the WCF 3.0 experience. It looks like we have always intentionally mitigated this threat.

Hope that helps to explain it a little more. We will still investigate in the next release if there's a way to safely expose the details of the SecurityException more readily in IErrorHandler, but hopefully the workaround is reasonable for now.

Thanks for the feedback,

-- Dave, WCF Team
Posted by CrazyLegsFitz on 6/9/2009 at 5:03 AM
Dave,

I appreciate your team looking at this. I don't understand the line that says, "Since this exception is not related to any service model exceptions, it cannot be handled by IErrorHandler". In my example, InvalidOperationException is part of the System namespace and is not directly related to any service model exception yet it gets picked up correctly by IErrorHandler. And just to be more specific, its the HandleError method on this interface where I'd like the original exception. Since nothing is going back to the client in this method there should be no danger of exposing private information to the world. In my view, the ProvideFault method can receive a FaultException as it's getting now just to ensure that no confidential information is exposed.

We are operating in a partial trust environment which is we see these SecurityExceptions.

In the meantime, we are using your workaround of looking in the WCF tracelogs and that does work but they are difficult to interpret even with the viewer.

Thanks
Posted by Microsoft on 6/8/2009 at 1:50 PM
Hello,

We spent some more time investigating this issue and have found that this is because SecurityException is related to CAS (Code Access Security), and it is a fatal exception. Since this exception is not related to any service model exceptions, it cannot be handled by IErrorHandler.

We will certainly look into addressing this is in a future release if it doesn't require a significant design change.

Thanks again for the feedback,

-- Dave, WCF Team
Posted by Microsoft on 10/21/2008 at 1:06 PM
Thank you for the feedback. The reason we special-case SecurityException today is so that we can send back a well-defined AccessDenied SOAP fault. E.g. If PrincipalPermission.Demand throws SecurityException, we convert it into a fault exception.

As you've found, we do this before it hits the error handler. Moving this logic to after the error handlers are scheduled is definitely a reasonable request in order to improve usability when debugging. We will investigate making this change in a future release. Regardless, the security exception does get traced by WCF before it is converted to a fault exception, so you're not completely stuck here. Hopefully you have been able to workaround this for now.

Please let us know if you have any other feedback! That's the best way to ensure that the product is improving release-by-release. Thanks!

-- Dave, WCF Team

Sign in to post a workaround.