Inspiring

Answered

Case sensitive paths

Forum|Forum|3 years ago
January 17, 2023
3 replies
839 views

Hi,

Stack; IIS+CF2021

I'm trying to use the ColdFusion Security Sandbox with a pretty sophisticated ecosystem and I've noticed that parts of it tend to give java access denied errors if they are not accessed with the proper caseSensitivity.

Imagine you have a sandbox entry for:

E:\inetpub\wwwroot\someDirectory\

That allows you to see:

E:\someFiles\ and E:\someFiles\-

This all works great in most cases. But then if someone gets to the website like https://someweb.com/someDirectory/index.cfm it works fine.

Then if they somehow get to

https://someweb.com/somedirectory/index.cfm

It does NOT always work.

The error message with the 'access denied' ALWAYS has the exception error struct with the relevant tag.Context."TEMPLATE" member saying:

E:\inetpub\wwwroot\somedirectory\index.cfm

You can go correct the link in your browser:

https://someweb.com/someDirectory/index.cfm

And it might still fail. IIS captures the link right in the logs.

Only ColdFusion's tagContext.template path is wrong, and doesn't update consistently.

What exactly is going on here? How can I make sure ColdFusion is trying to access the correct case sensitive path; since Java needs that.

It looks like it's being cached.. these errors are making the sandbox quite hard to implement without a high degree of stress.

This topic has been closed for replies.

Correct answer Selene Corvin

If anyone runs into this later, the following testing proves it; along with the solution:

restart CF

try#1- http://someurl.com/somedir/crc/ -- no rewrite (should not work)

restart CF

try#2- http://someurl.com/somedir/crc/ -- rewrite to someDir (should work)

restart CF

In application.cfc, I have a rewrite if they arrive at somedir to go to someDir at the onRequestStart event. I'm sure it works fine on the IIS level too, or nginx, apache w/e, but I'd rather not carry that baggage.

Hopefully Adobe can fix this at some point, since it should not be working in this fashion.

try#3- http://someurl.com/someDir/crc/ -- no rewrite (should work)

Selene CorvinAuthor

Inspiring

After creating a demo environment, my suspicions are kind of the case.

Say you fill out a form to upload a file.

https://someweb.com/somedirectory/uploadForm.cfm

And the file goes to E:\somefiles\

If the sandbox entry for E:\inetpub\wwwroot\someDirectory\ is cased like that (someDirectory)

It becomes important which link a user tries first. If they arrive at the above URL, it fails.

Then even if they change it to https://someweb.com/someDirectory/uploadForm.cfm it fails, because in the scope variables;

CF_TEMPLATE_PATH=E:\inetpub\wwwroot\somedirectory\uploadForm.cfm
and

PATH_TRANSLATED=E:\inetpub\wwwroot\somedirectory\uploadForm.cfm

If I restart the CF server at this point, and go directly to:

https://someweb.com/someDirectory/uploadForm.cfm

The variables are caseCorrect.

CF_TEMPLATE_PATH=E:\inetpub\wwwroot\someDirectory\uploadForm.cfm
and

PATH_TRANSLATED=E:\inetpub\wwwroot\someDirectory\uploadForm.cfm

Then submiting the form works as expected. And it will work even if you switch it to the wrong casing until whenever that cache clears.

At least I know what's going on. I'm going to do more testing with URL rewrites now to see if I can completely circumvent this bug.

Selene CorvinAuthorCorrect answer

Inspiring

If anyone runs into this later, the following testing proves it; along with the solution:

restart CF

try#1- http://someurl.com/somedir/crc/ -- no rewrite (should not work)

restart CF

try#2- http://someurl.com/somedir/crc/ -- rewrite to someDir (should work)

restart CF

In application.cfc, I have a rewrite if they arrive at somedir to go to someDir at the onRequestStart event. I'm sure it works fine on the IIS level too, or nginx, apache w/e, but I'd rather not carry that baggage.

Hopefully Adobe can fix this at some point, since it should not be working in this fashion.

try#3- http://someurl.com/someDir/crc/ -- no rewrite (should work)

Charlie Arehart

Community Expert

Thanks for sharing your workaround, in concept at least, of doing a "rewrite" in your application.cfc. To help others who may find this, it could help to clarify a couple of things, since you've shared no code. If you're open to elaborating even just a little, I can offer a couple of leading quesitons:

1) First, since you refer to doing onRequestStart, you could be doing whatever you want before processing the requested template. Are you perhaps doing a cfinclude based on the CGI scope's cf_template_path you show using? or doing a cflocation to it (which would technically be a "redirect")?

If you were doing an onRequest (instead of onRequestStart), we might presume you're manipulating the "targetPage" variable before doing what's typically done in an onRequest method:

(And switching to that may be something to consider, but I realize you may have other things you're already doing in your onRequestStart. Or what you've done may be fine for you.)

2) In either case, are you just using CF's replacenocase function against the incoming path (to find ANY variant of casing that a user might use), and then using lcase to turn that into a lowercased version?

3) Finally, it sure would be nice to get to the bottom of your problem, but I realize you just needed to workaround it to keep working. Would be nice also if Adobe might chime in with thoughts.

Again, thanks for what you've offered at least.

/Charlie (troubleshooter, carehart. org)

Charlie Arehart

Community Expert

Odd one, yes. And first I've heard of it. But the sandbox is woefully under-used. I wrote about it 20 years ago but see few leveraging it. (I don't think it's due to this difficulty. I just mean relatively few cf shops would experience the problem, to have shared knowledge about it widely.)

So what might you do?

first, for the problem of the error persisting despite your correction of the url, try going to the cf admin "caching" page, and click "clear template cache now". Does that make it go away? (Be sure to confirm you DO still get the error before trying that.) Let us know either way.
On the same page, do you show the "cache web server paths" being checked? If not I'm not saying to enable or disable it, or even if there's a connection to this problem. I'm just asking, as there MAY be one if it IS checked. Again, just confirm either way. Don't change it, based solely on my asking.

Again, someone may have better answers or diagnostics to consider. Offering this until then.

/Charlie (troubleshooter, carehart. org)

Selene CorvinAuthor

Inspiring

Thanks for the reply Charlie. Unfortunately 0/2 on those suggestions; we already had the cache web server paths unchecked, and the clear template cache doesn't change the error message showing the wrong path.

I am currently creating a demo environment for this and hopefully can pin down more info, but I'd appreciate any more ideas.

I'll update if I can get past this issue; already had to pull Sandbox off one prod server.

Selene CorvinAuthor

Inspiring

Clarification to OP (I can't seem to edit).

Basically, regardless if you fix the path, the error still detects the template path as the cache, which is probably why it's broken. So if you first try with 'someapp', even if you arrive at 'someApp' it doesn't change the error exception template in the tagContext. It still says /someapp/ for some reason.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded