• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Case sensitive paths

Community Beginner ,
Jan 17, 2023 Jan 17, 2023

Copy link to clipboard

Copied

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.

Views

260

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Community Beginner , Jan 18, 2023 Jan 18, 2023

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
...

Votes

Translate

Translate
Community Beginner ,
Jan 17, 2023 Jan 17, 2023

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jan 17, 2023 Jan 17, 2023

Copy link to clipboard

Copied

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)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 18, 2023 Jan 18, 2023

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 18, 2023 Jan 18, 2023

Copy link to clipboard

Copied

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.

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 18, 2023 Jan 18, 2023

Copy link to clipboard

Copied

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)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jan 18, 2023 Jan 18, 2023

Copy link to clipboard

Copied

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:

<cfinclude template="#Arguments.targetPage#"> 

 

(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)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 18, 2023 Jan 18, 2023

Copy link to clipboard

Copied

LATEST

1) in application.cfc onRequestStart, if a cgi.HTTP_URL contains the wrong casing of the path, the next action is a <cflocation> to the right one, appending the URI at the end. There are other ways to do this, but this seemed easiest.

 

2) In my current fix, I only know of 2 errant paths, so I do an exact find() and then do a replaceNoCase to replace that, but YMMV. If you are worried about stuff like soMeDiR you could harden the condition of course doing something more aggressive like !find('someDir', cgi.HTTP_URL, 1)>replaceNoCase.

 

3) Would be great if Adobe would chime in. It is a little crazy that there doesn't seem any way to prevent this kind of (errorneous) behavior, and also surprising that nobody else has had this issue and reported it.

 

Basically, if a user goes to the properlyCased url at first, it caches that and the sandbox works fine for a time. Even if the user changes it to properlycased.  Similarly, if they first go to properlycased and then try to fix it to properlyCased, it fails until the cache clears. This makes the error very stressful to debug, especially on production where you can't afford to just restart servers constantly.

 

Anyways, hopefully Adobe has something to say, because the sandbox is, in my opinion a neccessary feature, but it leaves a lot to be desired in terms of making you feel at ease with it's functions. I have a wiki entry full of quirks for it that are undocumented.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation