New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Execute function which returns RuntimePolicy isn't invoked #780

Closed
bsimanov opened this Issue Apr 23, 2014 · 14 comments

Comments

Projects
None yet
4 participants
@bsimanov
Contributor

bsimanov commented Apr 23, 2014

When I run my app in a debugger, the "Execute" function in GlimpseSecurityPolicy is only invoked when ExecuteOn returns RuntimeEvent.Initialize.

This causes problems when hitting certain routes which I want to exclude Glimpse from touching the HttpContext of.

For example, if I hit http://mysite/*.aspx I'd like Glimpse to run/collect data. When I hit http://mysite/myService/* I'd like for Glimpse to be off as it breaks the service security.

The issue with routes is related to Paul Atkin's post here: #736 however I feel if the "Execute" function invoked properly, then maybe I can code around this.

Thanks!

@bsimanov

This comment has been minimized.

Show comment
Hide comment
@bsimanov

bsimanov Apr 23, 2014

Contributor

Just did some digging through the code and did a bit of hacking... and it seems that when I add the following to the ignoreTypes:

Then my policy gets invoked for any RuntimeEvent... however, even though the policy is set to "Off" when invoking the service, the service still has security issues. Hmm...

Contributor

bsimanov commented Apr 23, 2014

Just did some digging through the code and did a bit of hacking... and it seems that when I add the following to the ignoreTypes:

Then my policy gets invoked for any RuntimeEvent... however, even though the policy is set to "Off" when invoking the service, the service still has security issues. Hmm...

@bsimanov

This comment has been minimized.

Show comment
Hide comment
@bsimanov

bsimanov Apr 23, 2014

Contributor

I guess this ticket can be closed/ignored.

I spent quite a few hours with the Glimpse code and realized it doesn't work quite like I thought. I thought turning the policy to "Off" would solve the issues, but that's not the way Glimpse works. It already makes changes prior to checking policies.

I wasn't able to track down the root cause of my particular issue, but I know it's created in the Glimpse.AspNet.HttpModule.Init routine. The only way to solve it in my case would be to have the blacklist URI policy applied in the Init routine prior to "BeginRequest" etc being invoked.

Contributor

bsimanov commented Apr 23, 2014

I guess this ticket can be closed/ignored.

I spent quite a few hours with the Glimpse code and realized it doesn't work quite like I thought. I thought turning the policy to "Off" would solve the issues, but that's not the way Glimpse works. It already makes changes prior to checking policies.

I wasn't able to track down the root cause of my particular issue, but I know it's created in the Glimpse.AspNet.HttpModule.Init routine. The only way to solve it in my case would be to have the blacklist URI policy applied in the Init routine prior to "BeginRequest" etc being invoked.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Apr 23, 2014

Collaborator

@bsimanov I think I know what the problem might be, but I need to make sure first if my assumptions are correct when reading your comments:

When I run my app in a debugger, the "Execute" function in GlimpseSecurityPolicy is only invoked when ExecuteOn returns RuntimeEvent.Initialize

That is normal, as Execute will only be called once during the initialization routine if RuntimeEvent.Initialize has been specified.
Subsequent requests won't be handled by a policy that only wants its Execute to be called on RuntimeEvent.Initialize

This causes problems when hitting certain routes which I want to exclude Glimpse from touching the HttpContext of.
For example, if I hit http://mysite/_.aspx I'd like Glimpse to run/collect data. When I hit http://mysite/myService/_ I'd like for Glimpse to be off as it breaks the service security.

What do you mean exactly with I'd like for Glimpse to be off as it breaks the service security What is the exact problem that Glimpse is breaking here?

Just did some digging through the code and did a bit of hacking... and it seems that when I add the following to the ignoreTypes:
<add type="Glimpse.Core.Policy.ControlCookiePolicy, Glimpse.Core"/>

Putting the ControlCookiePolicy in the list of ignored runtime policies has a net effect of Glimpse not checking for the cookie to be set, hence all requests will be monitored (if not restricted by another runtime policy)

Then my policy gets invoked for any RuntimeEvent... however, even though the policy is set to "Off" when invoking the service, the service still has security issues

Here I'm not following you anymore, a policy will only be invoked for all the runtime events it specifies that it wants to handle (BeginRequest, EndRequest, ...)
When you say "is set to Off" do you mean when your runtime policy is returning the value Off on Execute?

It already makes changes prior to checking policies

There are multiple policies being checked and currently there is no order defined, this might mean that even though your custom policy says Off that there were already other ones that have done some request validation to determine whether or not that specific policy should return Off or any of the other RuntimePolicy values

I wasn't able to track down the root cause of my particular issue, but I know it's created in the Glimpse.AspNet.HttpModule.Init routine. The only way to solve it in my case would be to have the blacklist URI policy applied in the Init routine prior to "BeginRequest" etc being invoked.

Does all of the above mean that you want Glimpse to prevent accessing the request's input stream so that your code has full access to it? Is that the error you're getting? Because we are aware of such a case when the AjaxPolicy is involved as it accesses the request's Request object to determine whether or not the request is an Ajax request, which means that ASP.NET will have read the input stream to populate that Request object.

If that is the case, then you could test that by disabling the AjaxPolicy

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
  <runtimePolicies>
     <ignoredTypes>
       <add type="Glimpse.Core.Policy.AjaxPolicy, Glimpse.Core" />
     </ignoredTypes>
  </runtimePolicies>
</glimpse>

If disabling works, then your issue is likely related to the following ones #498 and #360

Could you confirm/deny that it is the same issue, and if not, could you elaborate on the exact issue your are trying to work around? Put otherwise: what is exactly failing if Glimpse touches the http://mysite/myService/* requests

Collaborator

CGijbels commented Apr 23, 2014

@bsimanov I think I know what the problem might be, but I need to make sure first if my assumptions are correct when reading your comments:

When I run my app in a debugger, the "Execute" function in GlimpseSecurityPolicy is only invoked when ExecuteOn returns RuntimeEvent.Initialize

That is normal, as Execute will only be called once during the initialization routine if RuntimeEvent.Initialize has been specified.
Subsequent requests won't be handled by a policy that only wants its Execute to be called on RuntimeEvent.Initialize

This causes problems when hitting certain routes which I want to exclude Glimpse from touching the HttpContext of.
For example, if I hit http://mysite/_.aspx I'd like Glimpse to run/collect data. When I hit http://mysite/myService/_ I'd like for Glimpse to be off as it breaks the service security.

What do you mean exactly with I'd like for Glimpse to be off as it breaks the service security What is the exact problem that Glimpse is breaking here?

Just did some digging through the code and did a bit of hacking... and it seems that when I add the following to the ignoreTypes:
<add type="Glimpse.Core.Policy.ControlCookiePolicy, Glimpse.Core"/>

Putting the ControlCookiePolicy in the list of ignored runtime policies has a net effect of Glimpse not checking for the cookie to be set, hence all requests will be monitored (if not restricted by another runtime policy)

Then my policy gets invoked for any RuntimeEvent... however, even though the policy is set to "Off" when invoking the service, the service still has security issues

Here I'm not following you anymore, a policy will only be invoked for all the runtime events it specifies that it wants to handle (BeginRequest, EndRequest, ...)
When you say "is set to Off" do you mean when your runtime policy is returning the value Off on Execute?

It already makes changes prior to checking policies

There are multiple policies being checked and currently there is no order defined, this might mean that even though your custom policy says Off that there were already other ones that have done some request validation to determine whether or not that specific policy should return Off or any of the other RuntimePolicy values

I wasn't able to track down the root cause of my particular issue, but I know it's created in the Glimpse.AspNet.HttpModule.Init routine. The only way to solve it in my case would be to have the blacklist URI policy applied in the Init routine prior to "BeginRequest" etc being invoked.

Does all of the above mean that you want Glimpse to prevent accessing the request's input stream so that your code has full access to it? Is that the error you're getting? Because we are aware of such a case when the AjaxPolicy is involved as it accesses the request's Request object to determine whether or not the request is an Ajax request, which means that ASP.NET will have read the input stream to populate that Request object.

If that is the case, then you could test that by disabling the AjaxPolicy

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
  <runtimePolicies>
     <ignoredTypes>
       <add type="Glimpse.Core.Policy.AjaxPolicy, Glimpse.Core" />
     </ignoredTypes>
  </runtimePolicies>
</glimpse>

If disabling works, then your issue is likely related to the following ones #498 and #360

Could you confirm/deny that it is the same issue, and if not, could you elaborate on the exact issue your are trying to work around? Put otherwise: what is exactly failing if Glimpse touches the http://mysite/myService/* requests

@bsimanov

This comment has been minimized.

Show comment
Hide comment
@bsimanov

bsimanov Apr 24, 2014

Contributor

@CGijbels thanks for the very thoughtful response. I guess I didn't write too well, because there's some misunderstanding.

I've spent a LOT of time on this and finally found the issue! It's actually a problem with multi-part messages, which cause security issues when dealing with proxies (which is what I assume Glipse creates with the Castle Proxy). The issue and resolution are described here: http://support.microsoft.com/kb/908573 (Workaround section).

I tested the workarounds in the client code (NuGet), but I doubt the developers of NuGet will change that piece of code -- I'll report the issue there regardless.

As I stated earlier, it would be nice to have routes which are blacklisted from being proxied by the Castle Proxy.

Do you know if this is possible?

Contributor

bsimanov commented Apr 24, 2014

@CGijbels thanks for the very thoughtful response. I guess I didn't write too well, because there's some misunderstanding.

I've spent a LOT of time on this and finally found the issue! It's actually a problem with multi-part messages, which cause security issues when dealing with proxies (which is what I assume Glipse creates with the Castle Proxy). The issue and resolution are described here: http://support.microsoft.com/kb/908573 (Workaround section).

I tested the workarounds in the client code (NuGet), but I doubt the developers of NuGet will change that piece of code -- I'll report the issue there regardless.

As I stated earlier, it would be nice to have routes which are blacklisted from being proxied by the Castle Proxy.

Do you know if this is possible?

@bsimanov

This comment has been minimized.

Show comment
Hide comment
@bsimanov

bsimanov Apr 24, 2014

Contributor

Just to contribute something back to the project, I found a small bug.

https://github.com/Glimpse/Glimpse/blob/master/source/Glimpse.AspNet/Tab/Routes.cs, line 164 should be changed from:
"routeModel.Url = routeModel.ToString();"

to:
"routeModel.Url = _routeBase_.ToString();"

glimpsefix

This will at least show you what type of route it is... I tried to figure out a way to actually get the details from RouteMagic, but RouteBase isn't exposed.

Contributor

bsimanov commented Apr 24, 2014

Just to contribute something back to the project, I found a small bug.

https://github.com/Glimpse/Glimpse/blob/master/source/Glimpse.AspNet/Tab/Routes.cs, line 164 should be changed from:
"routeModel.Url = routeModel.ToString();"

to:
"routeModel.Url = _routeBase_.ToString();"

glimpsefix

This will at least show you what type of route it is... I tried to figure out a way to actually get the details from RouteMagic, but RouteBase isn't exposed.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Apr 24, 2014

Collaborator

@bsimanov regarding blacklisting specific urls: Did you try to use the UriPolicy ? There you can configure requests that should not be handled by Glimpse

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
    <runtimePolicies>
      <uris>
        <add regex=".*/myService/.*"/>
      </uris>
    </runtimePolicies>
</glimpse>

Now it might still have to pass through the proxies, as the proxies are put in place at the start and apply for all requests, the only difference with requests that should not be treated because one or more runtime policies object, is that those take a shortcut directly to the original code instead of Glimpse specific code.

If the UriPolicy does not help, do you think you could create a sample that reproduces the problem you're having? That way we can see how the flow goes and if there is something we can do to address this.

Regarding your last comment, feel free to create a separate issue for that and if you could provide a pull request with the change you made than we'll be happy to pull it in as well as it seems a good suggestion. That way your contribution will be a lot more visible on the Glimpse status board and in the release notes later on

Collaborator

CGijbels commented Apr 24, 2014

@bsimanov regarding blacklisting specific urls: Did you try to use the UriPolicy ? There you can configure requests that should not be handled by Glimpse

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
    <runtimePolicies>
      <uris>
        <add regex=".*/myService/.*"/>
      </uris>
    </runtimePolicies>
</glimpse>

Now it might still have to pass through the proxies, as the proxies are put in place at the start and apply for all requests, the only difference with requests that should not be treated because one or more runtime policies object, is that those take a shortcut directly to the original code instead of Glimpse specific code.

If the UriPolicy does not help, do you think you could create a sample that reproduces the problem you're having? That way we can see how the flow goes and if there is something we can do to address this.

Regarding your last comment, feel free to create a separate issue for that and if you could provide a pull request with the change you made than we'll be happy to pull it in as well as it seems a good suggestion. That way your contribution will be a lot more visible on the Glimpse status board and in the release notes later on

@PaulAtkins

This comment has been minimized.

Show comment
Hide comment
@PaulAtkins

PaulAtkins Apr 24, 2014

Contributor

@bsimanov - Ignore my comment, you're suggestion is completely right!

Contributor

PaulAtkins commented Apr 24, 2014

@bsimanov - Ignore my comment, you're suggestion is completely right!

@bsimanov

This comment has been minimized.

Show comment
Hide comment
@bsimanov

bsimanov Apr 25, 2014

Contributor

@CGijbels Yes, I've tried the uri policies, no go... the proxy is already active.

I've created a simple solution to recreate the issue. Warning: this may cause you to lose sleep and hair! :)

https://docs.google.com/uc?export=download&id=0B_QaHZhVy7Rgem1Ha2VOdTVuR2M
To recreate the issue, do the following:

  1. Compile the client project
  2. Launch the web project

In console, run the client. Run it again while turning the Glimpse defaultRuntimePolicy on/off. You'll see the issue :).

@PaulAtkins thanks for confirming! @CGijbels per your recommendation, I'll figure out how create a "pull request" and contribute to the project. Besides the visibility, it's good training to support the open source community.

Contributor

bsimanov commented Apr 25, 2014

@CGijbels Yes, I've tried the uri policies, no go... the proxy is already active.

I've created a simple solution to recreate the issue. Warning: this may cause you to lose sleep and hair! :)

https://docs.google.com/uc?export=download&id=0B_QaHZhVy7Rgem1Ha2VOdTVuR2M
To recreate the issue, do the following:

  1. Compile the client project
  2. Launch the web project

In console, run the client. Run it again while turning the Glimpse defaultRuntimePolicy on/off. You'll see the issue :).

@PaulAtkins thanks for confirming! @CGijbels per your recommendation, I'll figure out how create a "pull request" and contribute to the project. Besides the visibility, it's good training to support the open source community.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Apr 26, 2014

Collaborator

@bsimanov hmm, I'm running the application but I don't get an exception?

When I hit http://localhost:52459/defult.aspx, my name is shown as well as the Glimpse client panel

When I hit http://localhost:52459/myservice I get a 200 with my account name as description, so far so good no?
image

When I post to http://localhost:52459/UploadStuff I get a 200 with my account name as description, so far so good no?

So I'm trying to get my head around what is exactly going wrong for you? I must be missing a crucial part here?
Could you adapt the defult.aspx page to showcase a POST that might go wrong or a GET that fails?

Even when you go back to the defult.aspx page and show the history tab, you'll see all those posts and get stored in Glimpse...

image

Collaborator

CGijbels commented Apr 26, 2014

@bsimanov hmm, I'm running the application but I don't get an exception?

When I hit http://localhost:52459/defult.aspx, my name is shown as well as the Glimpse client panel

When I hit http://localhost:52459/myservice I get a 200 with my account name as description, so far so good no?
image

When I post to http://localhost:52459/UploadStuff I get a 200 with my account name as description, so far so good no?

So I'm trying to get my head around what is exactly going wrong for you? I must be missing a crucial part here?
Could you adapt the defult.aspx page to showcase a POST that might go wrong or a GET that fails?

Even when you go back to the defult.aspx page and show the history tab, you'll see all those posts and get stored in Glimpse...

image

@bsimanov

This comment has been minimized.

Show comment
Hide comment
@bsimanov

bsimanov Apr 26, 2014

Contributor

@CGijbels The reason it's working is because it seems you're just hitting the route in your browser. Instead, use the provided GlimpseIssue.Client.exe, which creates a multi-part message (to upload to the site).

Compile the Client project and execute it from command line.

Contributor

bsimanov commented Apr 26, 2014

@CGijbels The reason it's working is because it seems you're just hitting the route in your browser. Instead, use the provided GlimpseIssue.Client.exe, which creates a multi-part message (to upload to the site).

Compile the Client project and execute it from command line.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Apr 26, 2014

Collaborator

@bsimanov 😊 I think I should have read your comment more carefully as you clearly stated

  1. Compile the client project

I'll have a look at it later and will get back to you

Collaborator

CGijbels commented Apr 26, 2014

@bsimanov 😊 I think I should have read your comment more carefully as you clearly stated

  1. Compile the client project

I'll have a look at it later and will get back to you

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Apr 26, 2014

Collaborator

@bsimanov Alright, I was able to reproduce and the temporary solution is one of the suggestions I made above, namely to remove the AjaxPolicy

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
  <runtimePolicies>
     <ignoredTypes>
       <add type="Glimpse.Core.Policy.AjaxPolicy, Glimpse.Core" />
     </ignoredTypes>
  </runtimePolicies>
</glimpse>

This way you'll loose the Ajax detection, which makes sure the Glimpse client isn't sent back, but if you combine it with the UriPolicy as you did, then nothing will be monitored and you should be fine.

Problem is that the AjaxPolicy accesses the Request.Form collection when looking for a X-Requested-With value which prevents the input stream from being used later on :-(

Can you confirm that this workaround is working for you?

Collaborator

CGijbels commented Apr 26, 2014

@bsimanov Alright, I was able to reproduce and the temporary solution is one of the suggestions I made above, namely to remove the AjaxPolicy

<glimpse defaultRuntimePolicy="On" endpointBaseUri="~/Glimpse.axd">
  <runtimePolicies>
     <ignoredTypes>
       <add type="Glimpse.Core.Policy.AjaxPolicy, Glimpse.Core" />
     </ignoredTypes>
  </runtimePolicies>
</glimpse>

This way you'll loose the Ajax detection, which makes sure the Glimpse client isn't sent back, but if you combine it with the UriPolicy as you did, then nothing will be monitored and you should be fine.

Problem is that the AjaxPolicy accesses the Request.Form collection when looking for a X-Requested-With value which prevents the input stream from being used later on :-(

Can you confirm that this workaround is working for you?

@bsimanov

This comment has been minimized.

Show comment
Hide comment
@bsimanov

bsimanov Apr 28, 2014

Contributor

@CGijbels Sorry for the delayed response... YES! That fixed it! Didn't even need to combine it with a UriPolicy. THANK YOU!

Contributor

bsimanov commented Apr 28, 2014

@CGijbels Sorry for the delayed response... YES! That fixed it! Didn't even need to combine it with a UriPolicy. THANK YOU!

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Apr 28, 2014

Member

Thanks for letting us know. Given that this is related to AjaxPolicy I'm going to close this off.

Member

avanderhoorn commented Apr 28, 2014

Thanks for letting us know. Given that this is related to AjaxPolicy I'm going to close this off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment