I’m running apache2 & Tomcat. I thought I could return a 404 if I linked directly to application.cfc
But it returns a 200 and an empty response body (which is good), however that tells (the hacker) I’m using coldfusion (200 response).
In apache default.conf I have:
<Directory /var/www/vhosts/*****/www/>
<Files application.cfc>
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Files>
</Directory>
I would expect this to return a 404, any ideas why it doesn’t?
I disagree about ordering… this is a live aws server and I only want this file to be seen by 127.0.0.1
I have dozens of deny,allow following the same format and they all work.
As a test I put a mytest.htm in the root
with:
<Files mytest.htm>
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Files>
and it correctly prevented me from accessing it as the only allowed ip is 127.0.0.1
and I was accessing it from my browser using: 204.191.69.**
Maybe its because apache doesn't handle cfc extensions so it is then picked up by tomcat?
Chiming in here, because I think I know what the problem may be.
I did some experiments in the past with Tomcat and Apache2, creating a matrix of which directives preceed over others, also depending where the directives have been added (apache2.conf vs virtualhost.conf vs .htaccess).
What I’ve found is that the proxypass directive may preceed in certain situations over other rules (e.g. urlrewrite). That means, the proxypass directive for .cfc files may get fired even before your deny rule for application.cfc may apply.
I’m not sure if this is the case in your issue and scenraio, but it may deserve a try. To understand it better, please see my post in this other thread
You may need to move your proxypass directive to work from within an urlRewrite.
Yes andreas I’m sure you’re on the right track with proxypass, As this is a live server I’m going to wait and see if anyone else notices they can get a 200 response calling their application.cfc as in:
https://mywebsite/application.cfc
at least its returning an empty response header…I just think it’s bad that it can be accessed at all outside the server. I’m thinking this may not be an easy fix!
In that case one working option would be to move your proxypass directive to work from within urlRewrite rule with the [p] flag as shown in the threads I’ve already linked above.
Then you may also be able to use your “file” directive as whished.
Another possible approach that I just came up is, using the OnCFCRequest method from within your application.cfc and check if its requesting for itself,and then fire a cfheader with 404 response or trigger cferror. Of course, depends on your scenario if its applicable to you. But sincerely, I never tried that before. Don’t know if that would work, just listing it here as an option.
I’m on my phone so can’t test things, but is this discussion implying that Lucee doesn’t just inherently block any calls to application.cfc or .cfm itself, the way ACF does and always has?
Or is this something specific to that specific web server configuration, perhaps? I’m not aware that any such config allows circumventing of ACF’s blocking of such requests.
Of course it’s great that a fix has been found and shared here, but is there a reason Lucee wouldn’t just block access to those two files inherently? Are there people who somehow intentionally leverage the freedom to call these, which may be preventing the Lucee team from inherently blocking their access?
Apologies if I’ve somehow misinterpreted or misunderstood something here.
this will rewrite it to ‘does-not-exist’ which as that file does not exist, Apache invokes the ErrorDocument handler instead and produces the 404 response.