SecurityException with DefaultNetworkCredentials

Nov 2, 2010 at 11:10 PM

Hi!

I am hosting BlogEngine.Net 1.6.1.0 and am seeing some issues with getting the DefaultNetworkCredentials property.

In BlogRoll I was able to rem the line out, but it seems that in other places the property is requested too. Quite a serious place is when js.axd is requested to serve JavaScript and it fails on the line.

You can't see that off hand on the pages, but the sites fails to produce proper js scripts with js.axd module.

 

It fails in the lines of the code that call:

client.Credentials = CredentialCache.DefaultNetworkCredentials;

 It can be seen if you run fiddler. It turns out that one of the references to jscript returns a HTTP302 that redirects to the error (HTTP404) page.

 The link to the script that fails is the one:

http://[blogaddress]/js.axd?path=http%3a%2f%2fwww.neron.com.pl%2fblog%2fWebResource.axd%3fd%3dVjwlIqi7esLpp02YYsQj5vb-ws10arl6pmfvuDlShTmJbrmWkcW18HyiP3-g-C-LuV80Q3XQAy-AV4njmeyBLCbw27o1%26amp%3bt%3d634210112612724343

(or some other identifier as the id generated might depend on session or maybe some other factors).

 To see precisely the link that fails for you, run Fiddler (or similar HTTP monitoring tool) and look for the link that is similar to the above and generates 302 with redirect to http://[blogaddress]/error404.aspx?aspxerrorpath=/blog/js.axd

 

If you turn CustomErrors (set to Off) in Web.config for the /blog/application.

Then you will get the error page with the call stack:

Security Exception

Description: The application attempted to perform an operation not allowed by the security policy.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. 

Stack Trace:

[SecurityException: Request for the permission of type 'System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]

   System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) +0

   System.Security.CodeAccessPermission.Demand() +58

   System.Net.CredentialCache.get_DefaultNetworkCredentials() +62

   BlogEngine.Core.Web.HttpHandlers.JavaScriptHandler.RetrieveRemoteScript(String file) in JavaScriptHandler.cs:115

  BlogEngine.Core.Web.HttpHandlers.JavaScriptHandler.ProcessRequest(HttpContext context) in JavaScriptHandler.cs:43

   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +181

   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

--------------------------------------------------------------------------------

Version Information: Microsoft .NET Framework Version:2.0.50727.4206; ASP.NET Version:2.0.50727.4209

As a result, the java script files are not properly generated and there are jscript errors that make some featueres fail (like posting comments).

 

Please, let me know what you think of the error or if you know a remedy to it.

Coordinator
Nov 5, 2010 at 7:15 PM

You could try commenting out that line of code that sets client.Credentials.  I don't believe it's necessary.  Not sure if it will resolve the error, but worth trying.

Nov 6, 2010 at 9:32 AM

Hi, commenting out worked perfectly in case of the BlogRoll (App_Code/Controls/BlogRoll.cs, but this does not require a recompilation of the whole project, just redeploying the file.

There is quite a few such places in the code. Altogether there is 11 occurences, 9 of that in BlogEngine.Core project which requires recompilation, so I was more careful about that.

 

My quetion is: why the request for DefaultNetworkCredentials is there at all? Is it required? Why? If so, why the code (at least in case of BlogRoll.cs) works without that line?

Many people seem to observe the issue and most of the comments recommend doing a try around the line with an empty catch. Personally, I'm not in favour of such solution and rather had a reasonable if condition before the line (if I knew the conditions when to request the credentials and when not to) or get rid of the line if the code is not required.

Any hints around the reason to have the line or in what situation it's required?

Thx.

Coordinator
Nov 6, 2010 at 7:17 PM

I'm not aware of any time that settings the credentials to CredentialCache.DefaultNetworkCredentials is necessary.  There may be a situation where it's needed, but I'm not sure what that is.  The more typical reason to set "credentials" is when you have a specific username / password to set.

The problem here though is that that "SecurityException" error is occurring because in a strict medium trust .NET environment, it appears that setting the Credentials or using CredentialCache.DefaultNetworkCredentials is not allowed.  It would require being in a full trust environment, or probably also a modified medium trust environment.  A couple of others have ran into this and reported this here and here (not related to BE, but ASP.NET).

I think a lot of shared web hosts run with a modified medium trust policy.  An unmodified medium trust policy is a little too restrictive.  These web hosts will modify the default medium trust policy to allow a few unharmful things to be done.  My guess is that there's a lot of BE users who are using shared web hosting in these modified medium trust environments which allow setting Credentials (or referencing DefaultNetworkCredentials), and so they are not running into these errors.  A few others (e.g. yourself and others) are in a more restrictive environment, and are running into this.

You can probably safely comment out all these DefaultNetworkCredentials lines of code.

Nov 6, 2010 at 8:42 PM

Ben, thank you for the explanation. That lets me decide what to do further. I know that my hosters will not modify the medium trust environment, so I need to recompile the code with the lines remmed out. Thank you again.

Nov 6, 2010 at 9:04 PM
Edited Nov 6, 2010 at 9:10 PM
BenAmada wrote:

> I'm not aware of any time that settings the credentials to  CredentialCache.DefaultNetworkCredentials is necessary.  There may be a situation where it's needed, but I'm not sure what that is.

client.Credentials = CredentialCache.DefaultNetworkCredentials;  tells .NET to use Windows Integrated Authentication. In Windows Intranet environment ( IExplorer, IIS, Active Directory ) user does not need to provide username and password.
Instead of username / password IE sends a Kerberos Ticket, crypted token availabe in Windows shared memory after user Logon,   to IIS which authenticates user by passing token to Active Directory.

Other Web Browsers and Web Servers support now Windows Integrated Authentication as well.

> You can probably safely comment out all these DefaultNetworkCredentials lines of code.

 I would leave it.

 

Nov 7, 2010 at 4:23 PM

mvincic, thanks for the input. So what would be your recommendaiton to the issue I have with improperly generated JS files and some features due to that not working (like posting comments)?

In case of the BlogRoll.cs the quick fix helped to have the pages display at all when the widget was placed on the page. Otherwise, it was giving 404s every time.

 

Nov 8, 2010 at 10:56 PM
czarekn wrote:

> So what would be your recommendaiton to the issue I have with improperly generated JS files and some features due to that not working (like posting comments)?

You are hosting blogengine in a subdirectory and HTTP 302 / 404 error is in my opinion provoked by http://www.neron.com.pl ==> http://www.neron.com.pl/blog/ redirection that you do.
I am also hosting blogengine in a subdirectory and once also had security exceptions. Do not have this anymore since I defined a Virtual Directory using Hosting control Center Web App of my provider.

So, please try to replace your redirect page with Virtual directory similar to following one :

http://www.neron.com.pl/blog/   d:\neron.pl\blog Application = Yes

 

 

 

 

 

Nov 28, 2010 at 5:01 PM

I believe it has nothing to do with the security exceptions. Most often, when I test, I go directly to the http://www.neron.com.pl/blog/ url, so it skips the redirect.

And, removing the DefaultNetworkCredentials simply helped in case of the BlogRoll. It was easier, as it was an aspx and didn't require recompile of the whole project. I shall test remming out the rest of the lines with DefaultNetworkCredentials call and let you know the result.

Nov 29, 2010 at 9:30 AM

> I believe it has nothing to do with the security exceptions.

I guess that redirection  introduces problems to urls like following one from Web.config

<authentication mode="Forms">
<forms timeout="129600" name=".AUXBLOGENGINE" protection="All" slidingExpiration="true" loginUrl="~/login.aspx" cookieless="UseCookies"/>
</authentication>

> And, removing the DefaultNetworkCredentials simply helped in case of the BlogRoll.

This way you actually removed Windows Integrated Authentication, which is acceptable in your case,  but other BE users might need this feature.
DefaultNetworkCredentials puts only a Kerberos token in HTTP header.