search

Letractively / securityswitch

Automatically exported from code.google.com/p/securityswitch
Other
0 stars 0 forks source link

Potential Issue w/ ashx calls #39

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
Just switched from WebPageSecurity.dll to SecuritySwitch.
Telerik's RadProgressArea/Manager fails w/ a XML Exception on any SECURE page.  
It appears that the ajax calls to get the progress status are being mangled.  
Configuration is set to ignoreAjaxRequests.

Only thing I can think of is there is an issue w/ the .ashx handler used by the 
progress area.  If I add that to the ignore list - the errors stop but the 
progress area still does not display.

Original issue reported on code.google.com by Bill.ON...@gmail.com on 16 Apr 2012 at 7:05

GoogleCodeExporter commented 8 years ago 
I have used the module successfully with .ashx handlers.

I suppose it's possible that Telerik is not the standard AJAX header that the 
module is looking for (X-Requested-With=XMLHttpRequest). That said, you could 
add an ignore that takes care of all the Telerik handler paths.

The below path rule will ignore ALL .ashx handler URLs.
<add path="\.ashx(?:[/\?#].*)?$" matchType="Regex" security="Ignore" />

Assuming that all of Telerik's handlers match some pattern, like RadXXX.ashx, 
you could use a path rule like the following.
<add path="Rad[0-9a-zA-z\-_]+\.ashx(?:[/\?#].*)?$" matchType="Regex" 
security="Ignore" />

If that doesn't work for you, I suggest examining what the Telerik controls are 
sending, and how, (request data) via the developer tool in your browser of 
choice. Specifically, see what request headers are being sent and if there is a 
pattern to the .ashx URIs being requested you can exclude.

Let me know if you come to a solution or need more.

Original comment by vent...@gmail.com on 17 Apr 2012 at 12:33

GoogleCodeExporter commented 8 years ago 
The regex appears to have worked.  Out of curiosity - how has the code changed 
from the WebSecurity.dll code that this would have become an issue.  Previously 
I didn't have to be as concerned w/ the IGNORE configurations to make things 
work - just curious what advantage this setup has.

Original comment by Bill.ON...@gmail.com on 17 Apr 2012 at 1:40

GoogleCodeExporter commented 8 years ago 
The old WebSecurity.dll had less support for this type of thing. In fact, it 
had no way of ignoring AJAX requests, short of individual ignore rules for 
URIs. It's path rules for files only supported actual files paths (i.e., 
~/customers/Default.aspx but not ~/customers/). It also did not support rules 
beyond the file extension for a request (for example, you could not secure 
~/default.aspx?pageid=3, but not ~/default.aspx?pageid=4). The new module 
provides a way for all of these scenarios.

My guess is you are using a new version of IIS (i.e., from IIS6 to IIS7), or 
you were using IIS7 in Classic Mode before and are now using it in Integrated 
Mode. Is that the case? With Classic Mode or earlier versions of IIS (like 6 
and below), these same problems you are experiencing would only show up if you 
mapped all requests through the ASP.NET processor (wildcard mapping).

With IIS7 in Integrated Mode, all requests go through the ASP.NET pipeline; 
thus the need to tell this module to ignore more types of requests. Check out 
this article for more information:
http://learn.iis.net/page.aspx/508/wildcard-script-mapping-and-iis-integrated-pi
peline/

I'm still curious about how Telerik is issuing AJAX requests, but I don't have 
a copy of their products. Perhaps I will install a trial or contact their 
support to get to the bottom of this particular issue.

Original comment by vent...@gmail.com on 17 Apr 2012 at 4:25

GoogleCodeExporter commented 8 years ago 
That's the odd thing - no change in any other configuration - same application, 
same IIS (7 - integrated mode.)

With SecuritySwitch I had to be sure to IGNORE the App_Theme & image 
directories to avoid broken security (due to http:// elements) - and then I had 
to accommodate for the Telerik .ashx.  None of these were an issue w/ the older 
code - but I'm not sure WHY.  It seems like it would have been.

fwiw - the Telerik issue seemed to only be w/ its PROGRESSAREA control (part of 
RadUpload - but it can be used on its own.)  Other (more standard) AJAX calls 
using Telerik controls seemed to not have an issue.

Original comment by Bill.ON...@gmail.com on 17 Apr 2012 at 11:05

GoogleCodeExporter commented 8 years ago 
And to clarify - I believe the reason the other AJAX calls had no issues is 
that they were callbacks to the same .aspx page (and thus matched security 
settings.)  The PROGRESSAREA callbacks were to the handler - which was being 
rewritten/redirect to http when called from a https page.

Original comment by Bill.ON...@gmail.com on 17 Apr 2012 at 11:07

GoogleCodeExporter commented 8 years ago 
Okay, I understand now. Yes, the old WebPageSecurity library made quite a few 
assumptions. One of them was about what types of requests to handle. Another 
was about what constitutes a built-in handler and a standard handler.

The new library makes no such assumptions. I am considering having conventions 
that you can turn on for 80-90% of usage scenarios (e.g., ignore all images, 
style sheets, system handlers, etc.). That would make the module act more like 
the old one out of the box, but still offering all the new power. Of course, 
you could turn off the conventions and configure everything yourself too.

Does that sound like something beneficial?

Original comment by vent...@gmail.com on 18 Apr 2012 at 12:15

GoogleCodeExporter commented 8 years ago 
Sounds like the best of both worlds.  Certainly beneficial.

Original comment by Bill.ON...@gmail.com on 18 Apr 2012 at 2:36

GoogleCodeExporter commented 8 years ago

Original comment by vent...@gmail.com on 16 Jun 2012 at 2:14