Category Archives: Configuration

Protect Glimpse.axd with your custom runtime policy

Let’s first start with a quick recap on how Glimpse decides whether or not to aggregate and store diagnostic data for a specific request and how it protects its own resources for unauthorized access. (Glimpse resources are, for instance, the Glimpse client JavaScript file, the metadata that makes up the Glimpse panel, but most importantly the aggregated diagnostic data of the last and previous requests.)

To make sure Glimpse doesn’t show possibly sensitive diagnostic data, it allows you to create a custom runtime policy. This, based on your rules, authorizes or prevents the Glimpse Runtime from returning the aggregated data or even from running in the first place – all of this is determined per request. The Glimpse cookie for instance, which is what drives the “Turn Glimpse On” button, is checked by the ControlCookiePolicy, and is not used to prevent access to aggregated data but rather to inform the Glimpse Runtime whether or not it should collect information during the execution of a request.

All is not lost however. Glimpse is secure by default because it registers, out of the box, the LocalPolicy. The LocalPolicy is a runtime policy that checks whether or not a request has been made from the local machine and if this is not the case, then Glimpse will not aggregate data and certainly not return (previously) aggregated data. This is also the policy that must be ignored in the web.config if you would like to get Glimpse diagnostics from a remote server.

Now if you remove the LocalPolicy, then basically everything is out in the open. There is nothing protecting you from having Glimpse gathering diagnostics and returning this to the person making the request. You could disable Glimpse completely in the web.config by setting the defaultRuntimePolicy=”Off” in the glimpse config section, but then there is not much for you to personally get either.

So you need to replace the LocalPolicy with your own custom security policy. Which sounds harder than it is – usually only a few lines of code are involved. There might already be an example of such a policy in your project (albeit commented out) if you installed the Glimpse.AspNet NuGet package, just look for a file named GlimpseSecurityPolicy.cs

GlimpseSecurityPolicyExample

What does this example policy do? Well if you compile this as is, then Glimpse will discover this policy and will ask the policy, by calling Execute at then end of a request (ExecuteOn has a value of RuntimeEvent.EndRequest), whether the client is allowed to see the aggregated data or not. This example will only allow this if the current authenticated user is a member of the Administrator role, but you can put any kind of logic in there if you want, just keep in mind that this will be called for every request that is being monitored by Glimpse.

In case you’re wondering why the check is done at the end of the request instead of the beginning (as Glimpse might already have monitored the request then), it’s because some things like the current User might not yet be set in the beginning, hence disabling Glimpse for every request. But depending on your logic (IP check for instance) you can change this value to RuntimeEvent.BeginRequest

Securing Glimpse.axd

Now all of this was already possible with previous versions of Glimpse. But there was one thing that was not protected by such a custom security policy and that was the Glimpse.axd. This was due to the fact that if the same runtime policies would have been applied, then the Glimpse.axd might not be accessible in the first place because the ControlCookiePolicy could not find the Glimpse cookie and you need (at least to begin with) the Glimpse.axd to set the cookie (and maybe add the bookmarklets to your favorites bar for later use). This is why the runtime policies were explicitly being ignored by Glimpse for the default resource aka Glimpse.axd

You might wonder why you would secure the Glimpse.axd in the first place? Although it doesn’t give you access to the aggregated data, there is still quite some information being shown that might be useful to persons with bad ideas. Today the Glimpse.axd shows you how Glimpse is configured, maybe tomorrow we would like to provide you with the possibility to make changes to the configuration at runtime, who knows.

Securing Glimpse.axd as we used to do
There were several ways to lock the Glimpse.axd down because Glimpse wouldn’t. I’ll only show two of them, because some others are a little bit hacky and those two mentioned below can still be used today if you want to:

  1. Leverage the ASP.NET Security Model : By adding a location element to your web.config you can restrict access to the Glimpse.axd to Administrators only. Of course this is only possible if your authorization checks can be satisfied with a role checkglimpseaspnetlocation
  2. Security by obscurity : We’ve been talking about Glimpse.axd but there is no compelling reason to keep it named like that, you can name it whatever you like as long as you adapt your web.config accordingly you are good to go. But again, it’s not bullet proof if somebody can guess really wellSecurityByObscurity

Securing Glimpse.axd the way forward
As of release 1.7.0 of Glimpse, you can now secure the Glimpse.axd by using the same custom security policy as shown above. This has the benefit that your authorization rules with regards to Glimpse are stored in one place being your custom security policy and you no longer need to rely on security by obscurity or role checks (if that was even possible). And there is only one thing that you need to do for that which is modifying the ExecuteOn property of your custom security policy, so that it will not only be called at BeginRequest or EndRequest but also when a resource is being executed (our default resource aka Glimpse.axd) by updating ExecuteOn to:

public RuntimeEvent ExecuteOn
{
    // The bit flag that signals to Glimpse that it should run on either event
    get { return RuntimeEvent.Endrequest | RuntimeEvent.ExecuteResource; }
}

GlimpseSecurityPolicyExampleWithExecuteResource

Voila, that’s all there is to it

Now there are no more reasons why your Glimpse.axd can’t be secured. If there is something not clear or working, don’t hesitate to contact us on our issues list

Glimpse and HTTP Compression

Well its been a while since our last post, during this time we have been heads down and trying to get the next release out. This effort has been using up the majority of our time, but it will be worth the wait and is poised to be our best release yet. If you are interested in the blow-by-blow accounts feel free to subscribe to the Mailing List or track our Commits.

In this release we have been looking to close out the majority of our outstanding issues in GitHub. With this in mind we have gone through and closed out almost all our 80 issues. This has been no easy task and has forced us to look at problems we have been avoiding for a long time.

One of the biggest has been the conflict between Glimpse and sites that have HTTP Compression turned on. For more time than I care to admit, we have been avoiding this as we didn’t have a very good solution for the problem. But finally Nik came up with an innovative way to get around this issues.

As it turns out (and I know this is stating the obvious) you can alter the HTTP payload after it has been compressed. Unfortunately, with the way that Glimpse leveraged a HttpModule to alter response payloads and the way the ASP.NET pipeline works, we can’t guarantee that we would come before the compression would take place. Hence, if ever Glimpse ran after compression it would destroy the response – obviously something that people weren’t happy with.

Given this, we needed a way to ensure that the necessary script tags would be included in the payload before compression takes place. The answer was to create an Html helper (or like concept) that the developer would “manually” put into the sites master page. This helper would render out the required tags and signal the main system not to run its usual logic. Here is an example of how looks:

In MVC applications, simply add the following HTML helper call in your layout file right before the </body> tag:

@Html.GlimpseClient()

You will need to also add @using Glimpse.Mvc.Html to your view or in web.config.

In WebForms applications, you place the following server control before the </body> tag.

You will also need to register the Glimpse control at the top of your page or in web.config.

<%@ Register TagPrefix="glimpse" Namespace="Glimpse.AspNet.Controls" Assembly="Glimpse.AspNet" %>

We realize that this deviates from the usual “it just works” mantra, but unfortunately in this case when you are using Compression, it looks like this is the best solution.

To get this update, you can either wait for the v1 RC2 or checkout the Daily Builds. Let us know how you get on.

Blacklisting and Remove Plugins

In an effort to try and make some of the lesser known features of Glimpse some air time, we thought we would put together a few short posts on how to perform a coupe of tasks that might get you some quick wins.

First in the list is Blacklisting/Remove Plugins. Out of the box Glimpse provides several plugins. Depending on what version of Glimpse you go for (Glimpse
or Glimpse.MVC3) you will have a variety of tabs that serve different purposes.

We are still refining the list of what is useful and what people want to see, but if there is something you don’t want, removing it is quite straight forward. In this case you would simply add a “pluginBlacklist” element to your glimpse config and using the fully qualified name of the plugin, add items to the blacklist:

<glimpse>
      <pluginBlacklist>
            <add plugin="Glimpse.Mvc3.Plugin.MetaData" />
            <add plugin="Glimpse.Mvc3.Plugin.Binders" />
            <add plugin="Foo.Bar.GlimpsePlugins.CurrentUser" />
      </pluginBlacklist>
</glimpse>

*It should be noted that if you wanted to blacklist 3rd party plugins, this is more than possible using the same method, as demonstrated with the Foo.Bar.GlimpsePlugins.CurrentUser line above.

Other cases where you might want to blacklist plugins, is for different environments. Lets say, if in development you want all tabs, but in UAT, you want half of them removed and in PROD you only want tracing, Glimpse can support this. You could have several reasons to do this like reducing payload size, or for security concerns. All you would need to do is blacklist the plugins you don’t need in the config file for each environment.

If should be noted that, if you blacklist a plugin, not only do we not show that tab, but the plugin never gets wired into the life-cycle of the page. Blacklisted plugins add absolutely no overhead and are never instantiated.

Hope that helps and let us know what you think and if we can do anything more in this area.