6 Replies Latest reply on Feb 6, 2012 5:15 PM by justin_at_adobe

    Risks using querybuilder.json

    liorz_adok Level 1

      Hi,

      I noticed that /bin/querybuilder.json is blocked for access as part of the default dispatcher.any configuration

       

      What are the risks of enabling this path to be available publically?

      Is there any options of limiting the pathes within the jcr that can be retuned for queries submitted ?

       

      Lior

        • 1. Re: Risks using querybuilder.json
          reusr1 Level 2

          in general, you can execute any query through the query builder - so if your anonymous user has read access to the full JCR tree then a malicious user can access anything in the repository. It may be better to actually use the query builder API in a similar way the search uses the querybuilder instead of opening it up to the world or write a set of restrictive mode_rewrite rules to avoid too much access to the query builder.

           

          Ruben

          • 2. Re: Risks using querybuilder.json
            liorz_adok Level 1

            thanks Ruben,

            can you clerify a bit what you meant by "write a set of restrictive mode_rewrite rules to avoid too much access to the query builder" ?

             

            Thanks,

            Lior

            • 3. Re: Risks using querybuilder.json
              reusr1 Level 2

              mod_rewrite allows you to use regular expressions to allow/disallow requests. This can be used to only allow certain parameters to be passed to querybuilder. However, I think it's not a good way to do this. Using the querybuilder from jsp or java is a better and more secure approach in my opinion. Maybe somebody from adobe wants to comment on this as well.

              • 4. Re: Risks using querybuilder.json
                aklimets Adobe Employee

                Agreed, for use on a publish site it might be better to have specific jsps that cover only the desired search and use the query builder API.

                 

                But it's still important to note that anything readable for anonymous is public anyway - the ACLs of your content should be right. The querybuilder uses the JCR search which fully respects ACLs in the result. An open query API such as the Sling .query.json or the querybuilder.json servlets just make the explorability of that public content easier.

                 

                Cheers,

                Alex

                • 5. Re: Risks using querybuilder.json
                  reusr1 Level 2

                  I guess the security checklist suggests using dispatcher to lock down

                  cq, not the ACL's - if one looks at the default ACL's for everyone that

                  CQ sets up in an install it's a bit too scare I would say to go with ACL

                  lockdown since /libs and /apps have full read access for everyone on a

                  pub instance and /content/uploadFilesTempDir has read/write access.

                   

                  Ruben

                  • 6. Re: Risks using querybuilder.json
                    justin_at_adobe Adobe Employee

                    One other thing to keep in mind is the performance impact. If you let anyone run arbitrary queries against the repository, you may be opening yourself up for performance problems. Even if no content is leaked because you have proper ACLs, your server may still suffer a performance issue.

                    1 person found this helpful