Solr
  1. Solr
  2. SOLR-1233

Remove restriction that /select cannot be used for /-prefixed request handlers via qt

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Component/s: search
    • Labels:
      None

      Description

      Currently /select?qt=/whatever is blocked by SolrDispatchFilter. It makes life a lot easier to make general requests to any request handler (for example in SOLR-1230 where dataimport.jsp needs to request to arbitrary handler names).

      1. SOLR-1233.patch
        1 kB
        Erik Hatcher

        Issue Links

          Activity

          Hide
          Ryan McKinley added a comment -

          For background, in the original RequestHandler design, we disallowed qt with leading '/' for security reasons.

          While solr does not internally support security, we need to make sure that it does not prevent standard path based security.

          +1 to put the restriction back

          Show
          Ryan McKinley added a comment - For background, in the original RequestHandler design, we disallowed qt with leading '/' for security reasons. While solr does not internally support security, we need to make sure that it does not prevent standard path based security. +1 to put the restriction back
          Hide
          David Smiley added a comment -

          I decided to move this discussion to a new issue: SOLR-3161
          Please comment there, not here.

          Show
          David Smiley added a comment - I decided to move this discussion to a new issue: SOLR-3161 Please comment there, not here.
          Hide
          David Smiley added a comment -

          I'm very surprised that I am the only one commenting on this issue. FWIW, in other private communication channels, I know there is support for what I want here among at least some committers.

          I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use "qt", but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that.

          Here is my proposal:

          • Solr should error if the parameter "qt" is supplied with a leading '/'. (trunk only)
          • Solr should only honor "qt" if the target request handler extends solr.SearchHandler.
          • The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including "/select?qt=mycustom" for handlers that aren't named with a leading '/'. This choice should be positioned at the top.

          And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above.

          Does anyone foresee any problems with this proposal?

          On a related subject, I think the notion of a default request handler is bad – the default="true" thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use <requestHandler name="/select" class="solr.SearchHandler"> instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the "default" attribute.

          Show
          David Smiley added a comment - I'm very surprised that I am the only one commenting on this issue. FWIW, in other private communication channels, I know there is support for what I want here among at least some committers. I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use "qt", but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter "qt" is supplied with a leading '/'. (trunk only) Solr should only honor "qt" if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including "/select?qt=mycustom" for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad – the default="true" thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use <requestHandler name="/select" class="solr.SearchHandler"> instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the "default" attribute.
          Hide
          David Smiley added a comment -

          I created issue SOLR-3040 which updates the admin UI to NOT use the qt parameter for working with the DIH.

          Show
          David Smiley added a comment - I created issue SOLR-3040 which updates the admin UI to NOT use the qt parameter for working with the DIH.
          Hide
          David Smiley added a comment -

          I found a solution, which is to disable qt by changing the default search handler named="search" to be name="/select":
          <requestHandler name="/select" class="solr.SearchHandler">
          instead of:
          <requestHandler name="search" class="solr.SearchHandler" default="true">

          Show
          David Smiley added a comment - I found a solution, which is to disable qt by changing the default search handler named="search" to be name="/select": <requestHandler name="/select" class="solr.SearchHandler"> instead of: <requestHandler name="search" class="solr.SearchHandler" default="true">
          Hide
          David Smiley added a comment -

          And I was hoping to find a way to disable this vulnerability in the solrconfig.xml... thinking that perhaps I could lock down qt with invariants, but that doesn't work. Presumably qt is special. I hate qt.

          Show
          David Smiley added a comment - And I was hoping to find a way to disable this vulnerability in the solrconfig.xml... thinking that perhaps I could lock down qt with invariants, but that doesn't work. Presumably qt is special. I hate qt.
          Hide
          David Smiley added a comment -

          Seriously?! I was just about to report a security oriented bug that the likes of this is supported:
          http://localhost:8983/solr/select?qt=/dataimport&command=full-import
          And get this... (as I say with a fiendish chuckle):
          http://localhost:8983/solr/select?qt=/update&stream.body=%3Cd%3E%3Cdelete%3E%3Cquery%3E*%3A*%3C%2Fquery%3E%3C%2Fdelete%3E%3Ccommit%2F%3E%3C%2Fd%3E

          Booyaaa! All your data is gone.

          And no, disabling remote streaming in the schema won't save you this time.

          Users expect /select to do a search and I don't think there should be any if's and's or but's about that expectation. I don't really like the qt parameter and think people should prefix their request handlers with a slash and access them directly, but I don't expect to change anyone's mind here. But if qt starts with a slash, then I think it should ideally not work, or for backwards compatibility sake, only support it if the target request handler has the same class as the current request handler.

          Show
          David Smiley added a comment - Seriously?! I was just about to report a security oriented bug that the likes of this is supported: http://localhost:8983/solr/select?qt=/dataimport&command=full-import And get this... (as I say with a fiendish chuckle): http://localhost:8983/solr/select?qt=/update&stream.body=%3Cd%3E%3Cdelete%3E%3Cquery%3E*%3A*%3C%2Fquery%3E%3C%2Fdelete%3E%3Ccommit%2F%3E%3C%2Fd%3E Booyaaa! All your data is gone. And no, disabling remote streaming in the schema won't save you this time. Users expect /select to do a search and I don't think there should be any if's and's or but's about that expectation. I don't really like the qt parameter and think people should prefix their request handlers with a slash and access them directly, but I don't expect to change anyone's mind here. But if qt starts with a slash, then I think it should ideally not work, or for backwards compatibility sake, only support it if the target request handler has the same class as the current request handler.
          Hide
          Grant Ingersoll added a comment -

          Bulk close for Solr 1.4

          Show
          Grant Ingersoll added a comment - Bulk close for Solr 1.4
          Hide
          Erik Hatcher added a comment -

          Committed.

          The Solr wiki is broken for saving at the time of writing, but this blurb belongs on the SolrSecurity page:

          == Request Handler Paths ==

          Solr provides access to request handlers through a general purpose /select?qt=request_handler_name URL. Prior to ["Solr1.4"] (via SOLR-1233), request handlers named with a leading forward-slash like /select?qt=/request_handler_name could not be used, but had to be requested using /request_handler_name. ["Solr1.4"] removes the forward-slash restriction and allows /select to work with any request handler name. Externally blocking access to /select is recommended in environments where only path-based access to request handlers is warranted.

          Show
          Erik Hatcher added a comment - Committed. The Solr wiki is broken for saving at the time of writing, but this blurb belongs on the SolrSecurity page: == Request Handler Paths == Solr provides access to request handlers through a general purpose /select?qt=request_handler_name URL. Prior to ["Solr1.4"] (via SOLR-1233 ), request handlers named with a leading forward-slash like /select?qt=/request_handler_name could not be used, but had to be requested using /request_handler_name. ["Solr1.4"] removes the forward-slash restriction and allows /select to work with any request handler name. Externally blocking access to /select is recommended in environments where only path-based access to request handlers is warranted.
          Hide
          Erik Hatcher added a comment -

          This patch removes the restriction on /select on hitting /-prefixed request handlers.

          Show
          Erik Hatcher added a comment - This patch removes the restriction on /select on hitting /-prefixed request handlers.

            People

            • Assignee:
              Erik Hatcher
              Reporter:
              Erik Hatcher
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development