tracker issue : CF-4202619

select a category, or use search below
(searches all categories and all time range)
Title:

Authenticated users bypass NTFS ACL permission authorization getting access to restricted CF content without error

| View in Tracker

Status/Resolution/Reason: To Track//PRNeedInfo

Reporter/Name(from Bugbase): John Dickinson / ()

Created: 05/25/2018

Components: Installation/Config, Connector

Versions: 2016,2018

Failure Type: Incorrectly functioning

Found In Build/Fixed In Build: Version 2016.0.06.308055 Tomcat Version 8.5.28.0 Java Version 1.8.0_172 /

Priority/Frequency: Major / All users will encounter

Locale/System: English / Win 2012 Server x64

Vote Count: 3

Problem Description:

A user with no rights in an area protected by NTFS permissions gets prompted for credentials (as they should), but once their credentials are entered, they get  access to "protected" CFM files. The same user with no rights accessing other content types (htm, asp, aspx, etc) in the protected area gets "Access denied" after entering credentials.  ColdFusion is not doing "authorization" to prevent their access to restricted CF content.

Steps to Reproduce:

    1. Find or create user account with no special rights for testing.
       This user should only have Anonymous access where allowed.

    2. Create a test subdirectory in web space.

    3. Configure the test subdirectory in IIS and NTFS:

         IIS Administrator:
           Change the test directory Anonymous Authentication to disabled.
           Change the test directory Windows Authentication to enabled.

         File system test directory NTFS security settings:
           Break inheritance
           Remove MACHINE/Users group (or similar) access

    4. Create a trivial test.cfm file in the test directory. 
         Using CF to display the authenticated user helpful.

           <p>This is test.cfm
           <cfoutput>
             <p>CGI.AUTH_USER is: #cgi.auth_user#
           </cfoutput>

     5. Test using Internet Explorer

        a. Enter URL for test.cfm

        b. When prompted for credentials, enter username and password
           for the user that has no rights. If prompted again, 
           enter the username and password one or two times more
           until a server response for the page is displayed.

        Note that Internet Explorer may not prompt for
        user credentials if "Automatic logon with current
        user name and password" is enabled in Internet Explorer.
        Internet Explorer may also remember and use the credentials
        for subsequent page request in the same session.

Actual Result:

    User sees restricted content. For test.cfm as above:

        This is test.cfm
        CGI.AUTH_USER is: domain\username (for user without rights)   

Expected Result:

      401.3 Access Denied or Not Authorized error

Any Workarounds:

    No acceptable workarounds were found.

    The IIS "URL Authorization" server role approach
    shouldn't be required and is not the desired solution.

    It may be possible to configure Tomcat to do NTFS authorization.

    The applications could be re-designed to lookup the authenticated
    user from CGI.AUTH_USER in a database of users.

Attachments:

Comments:

I have worked with John and his org on this, and I have verified the problem happens on my own machine also. It is indeed surprising that such protection of file access is not honored by CF (or the tomcat web server connector).
Vote by Charlie A.
28991 | May 31, 2018 05:43:22 PM GMT
Adding to the comment I made with my vote (on the right), I will add that I have confirmed that this also happens in pure Tomcat with JSPs and servlets (by this I mean I downloaded and installed Tomcat alone, and configured the web connector for it, manually.) And as with our testing in CF, I saw that in pure Tomcat also, the requests to HTM and other static files would get blocked by IIS (if one does not have permission to the folder where they live), whereas JSPs and servlets ran. So this clearly suggests it's something about the web connector. [For readers, CF configures a tomcat web connector when connecting IIS or Apache to CF. In IIS, that's about the tomcat isapi filter, the jakarta virtual directory, the CF config/wsconfig folders and their properties files and dll,and so on. And boy are we are lucky that CF offers that web server config tool to do all that for us! When setting up a pure Tomcat alone, we have to do all that and create and configure the properties files, etc. by hand!]
Comment by Charlie A.
28990 | May 31, 2018 05:49:44 PM GMT
+1, wow...........
Vote by Aaron N.
28992 | June 06, 2018 06:11:17 AM GMT
I have seen this behavior as well.
Vote by Peter F.
29005 | June 07, 2018 03:50:54 PM GMT
I will note that you can use the CF identity with NTFS permissions to control what files CF has access to. BUT that is not always a workaround as in this case the John wants to provide access to a cfm file only for certain users while blocking access for other users (based on NTFS). I do think that the CF connector should check that the "Logon User" has permission to access the file requested, but it can get more complicated when you think about cfinclude or CF accessing other files. CF will ofcourse perform the cfinclude and any other file operation with the identity that the ColdFusion service is authenticated as.
Comment by Peter F.
29004 | June 07, 2018 03:59:38 PM GMT
sent a mail to John for more information.
Comment by HariKrishna K.
29252 | July 06, 2018 09:38:16 AM GMT
My testing shows that this bug also affects using IIS "URL Authorization" seen in the IIS "Authorization Rules" feature in the IIS Manager. URL Authorization provides access control based on the URL string and Authorization rules rather than NTFS permissions settings. Unfortunately, IIS URL Authorization is susceptible to the same bug: Authenticated users bypass URL Authorization rules, getting access to restricted CF content without error.
Comment by John D.
29945 | November 19, 2018 10:00:00 PM GMT
John, Adding iis_authorization_enable = true inĀ isapi_redirect.properties, restart IIS, everything works. I have verified that the users' who has no rights would get 403 and the users who has access would be able to access the cfm's. I have tried it on CF 2016 and CF 2018. Let me know, if you need anything else here?
Comment by HariKrishna K.
30007 | December 05, 2018 12:52:38 PM GMT
Hi Hari, Will that be fixed in CF2016 and CF2018? Thanks!, -Aaron
Comment by Aaron N.
30022 | December 07, 2018 06:21:31 AM GMT
Hari, I'm glad to know the fix works for you. It appeared to cause new problems for me even if I remove the setting. My testing continues to show problems for CFM and HTM in directories with restricted rights. After the fix was added, NO USERS GET ASKED TO ENTER THEIR CREDENTIALS, despite removing the fix. ASP and ASPX test the same as HTM. 1. With fix: CFM request with rights gets 403 (Should be 200) 2. With fix: CFM request with no rights gets 403 (Correct, but user isn't asked for credentials) 3. With fix: HTM request with rights gets 401 (Should be 200) 4. With fix: HTM request with no rights gets 401 (Should be 403) 5. With fix removed: CFM request with rights gets 200 (Correct, but user isn't asked for credentials) 6. With fix removed: CFM request with no rights gets 200 (The original bug. Should be 403) 7. With fix removed: HTM request with rights gets 401 (Should be 200) 8. With fix removed: HTM request with no rights gets 401 (Should be 403) At this point I can restore the machine and try the fix again. I could also try the fix on another machine. I've been hesitant to do either before analyzing the current problems in more detail. I was just looking at an IIS Failed Request Trace for case 7 above. Can I send you that trace or another one? Let me know what I can do next to help.
Comment by John D.
30026 | December 07, 2018 05:34:45 PM GMT
CORRECTION: I realized that my test configuration was flawed. I need to retract the HTM results I posted above in my Tracker comment. Please ignore the HTM cases 3, 4, 7 and 8. I no longer feel that the fix causes problems for non-CFM pages or makes unwanted changes. I am still seeing that users both with and without rights to restricted CFM are not prompted to enter credentials. The user with rights to CFM still gets denied access in addition to the user without rights. Another tester's result would help to understand why Hari and I are seeing things differently.
Comment by John D.
30032 | December 09, 2018 11:02:29 PM GMT
I got a notification today that this bug had been changed from component "security" to component "connector", but there is no other comment from Adobe since early December (more on that in a moment). So first, can anyone from Adobe offer more on the change? Is it a mere technicality in what "component" this is in? Does it still get tracked as being a "security" issue somehow? (Perhaps a new field should be added to the tracker for folks mark issues as having security ramifications.) Second, note that there have been no replies here from Adobe to comments written since early Dec, both from the OP (John D) and from Aaron N. Considering also the confirmation of the problem by Pete F (last June), as well as mine when John first posted, it would be helpful to hear from someone about where things stand on this. I hope no one say John's last comment (above mine here), where he retracted a point. it was ONLY about htm pages, NOT a retraction of his concern about CFM page processing, so it seems the problem remains--unless Adobe may suggest otherwise. (There is nothing in the "fixed in build" field here, as I write this.)
Comment by Charlie A.
31080 | July 30, 2019 01:47:35 PM GMT
Hmm. Got a notification today that this bug report had been updated with a minor aspect of the component it's being tracked as, which I assume an Adobe person changed. But it's sad that it's been 14 months since the only brief interaction from an Adobe representative. Please see my previous comment, about how this matter seems to remain unresolved (and with Pete, Aaron, and myself chiming in, in addition to John D himself, I am surprised the issue has not raised more concern on the Adobe side).
Comment by Charlie A.
33131 | February 15, 2020 08:51:28 PM GMT
We switched our CF 2018 to use the BonCode Connector back in mid-September 2019. It installed easily, resolving this problem and finally making CF 2018 usable for us. The BonCode Connector has been working with CF 2018 as a production server without fail since that time. See http://www.boncode.net/boncode-connector
Comment by John D.
33133 | February 16, 2020 08:09:39 PM GMT