Getting the Most Out of SecurityException


Secure ASP.NET


Getting the Most Out of SecurityException


By Don Kiely


Have you ever written a partial trust ASP.NET application and gotten a SecurityException? SecurityException is the exception thrown by the .NET Framework whenever any kind of security problem arises most commonly when the code attempts to do something for which it doesn t have the code access security permissions. But SecurityException is a bit odd compared to other exception classes. For example, it doesn t directly expose the InnerException property, even though you can still get at it through the base SystemException object.


What SecurityException does do is expose some rich information about the source of the security problem that caused the Framework to throw it. For example, with the Demanded property, you can find out the demanded permission, permission set, or collection that caused a demand to fail. You can use the FirstPermissionThatFailed to find out the first permission in a permission set that failed a demand. You can also get the permission set definition that caused the exception, along with the URL and zone of the assembly that caused the exception. There is a lot of information in the exception object that can paint a detailed picture of exactly what went wrong.


But there s a problem. Often you ll catch the exception and try to get at all that juicy information, ready to do some good-old-fashioned security debugging. But when you try to read some of the exception object s properties, you instead get another SecurityException thrown! The problem is that, even though you can read some of the properties of the exception object, you may need a higher privilege to read other properties. The reason for the protection is that the contents of those properties can have some sensitive information that you don t want just anyone to be able to read.


The root problem is that the code doesn t have set the ControlEvidence and ControlPolicy flags of the SecurityPermission. You need those permissions to read the sensitive information. Each of these flags controls different information, so you need them both for the full set of information available in SecurityException.


And guess what? None of the standard partial trust levels in ASP.NET, not even the Medium and High trust levels, have those flags set.


So you have to run the application with Full Trust to get the information, right? NO!!! What you do need is to either define a custom trust level that has those flags set or sandbox the code to run safely. If you don t know how to do that, stop right now and read my Secure ASP.NET column from the June 2007 edition of asp.netNOW, Sandboxing Gotcha in a Partially Trusted App, then come back here to continue reading.


Sample Application

I wrote a simple application that shows how all this works. When run with full trust, the application reads and displays the C:\boot.ini file available by default on most versions of Windows. Here s what it looks like when run with Full Trust:



Nothing fancy in the code. It simply reads boot.ini into a StreamReader and displays the contents to a Label. Because boot.ini is readable by default by any user (that is, Windows grants Read permissions to anyone), and Full Trust shuts off any code access security permission checking, the contents appear on the page. Not good:


protected void PressButton_Click(object sender, EventArgs e)


     string path = @"C:\boot.ini";



           using (StreamReader reader = new StreamReader(path))


                       string content = reader.ReadToEnd();

                       ResultsLabel.Text = content;



     catch (SecurityException secEx)


           ResultsLabel.Text = secEx.ToString().Replace("\r\n", "




If you run the application with Medium Trust, the using statement causes a SecurityException. The catch block uses the exception object s ToString method to display the juicy details, and here is where you see that you get only a subset of the available information:



If you put a breakpoint on the statement in the catch block that writes to the ResultsLabel, then examine the secEx object in the Visual Studio Locals window, notice that several of the properties indicate that another SecurityException was thrown when trying to read several of the properties:



The ToString method ignores any properties that throw an exception, and returns only the information available to it.


The Solution

The solution is to run the code with elevated privileges, specifically defining SecurityPermission with the ControlEvidence and ControlPolicy flags set. The best way to do this is to sandbox code that has those flags set, and pass the security exception to that code to read the sensitive information. That way your entire application doesn t have to have dangerous permissions to run. (Again, see Sandboxing Gotcha in a Partially Trusted App for some of the details.)


To keep things simple here, I created a custom trust level that sets those flags and applies them to the entire application. This requires only a single change from the Medium Trust level in the customtrust.config file, which I show highlighted below:




  Flags="ControlEvidence, ControlPolicy, Assertion, Execution,

    ControlThread, ControlPrincipal, RemotingConfiguration"



To apply the custom trust level to the application, you also must modify its web.config file:




Now when you run the application, notice that you get far more information from the ToString method:



And if you examine the secEx object in the Locals window, you ll see that those pesky secondary exceptions aren t happening now:



Voil ! Now you have all the information you need to debug the problem and make your code secure.


Sample code accompanying this article is available for download.


Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at





Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.