Solr
  1. Solr
  2. SOLR-3419

XSS vulnerability in the json.wrf parameter

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.5
    • Fix Version/s: None
    • Component/s: Response Writers
    • Labels:
      None

      Description

      There's no filtering of the wrapper function name passed to the solr search service
      If the name of the wrapper function passed to the solr query service is the following string -
      %3C!doctype%20html%3E%3Chtml%3E%3Cbody%3E%3Cimg%20src=%22x%22%20onerror=%22alert%281%29%22%3E%3C/body%3E%3C/html%3E

      solr passes the string back as-is which results in an XSS attack in browsers like IE-7 which perform mime-sniffing. In any case, the callback function in a jsonp response should always be sanitized - http://stackoverflow.com/questions/2777021/do-i-need-to-sanitize-the-callback-parameter-from-a-jsonp-call

        Activity

        Hide
        James Frank added a comment -

        Just an agreement that this should be resolved and SOLR should be sanitize the json.wrf callback. We are facing an issue where this vulnerability was pulled up in a security scan and we will need to implement external sanitization through a proxy in order to resolve it. This is really something that should be happening internally.

        Show
        James Frank added a comment - Just an agreement that this should be resolved and SOLR should be sanitize the json.wrf callback. We are facing an issue where this vulnerability was pulled up in a security scan and we will need to implement external sanitization through a proxy in order to resolve it. This is really something that should be happening internally.
        Hide
        Stanislav Stolpovskiy added a comment -

        I tried to reproduce this on Solr 3.4 and html characters were automatically escaped in my case.
        Does it mean that this vulnerability is present only in 3.5 version?

        Show
        Stanislav Stolpovskiy added a comment - I tried to reproduce this on Solr 3.4 and html characters were automatically escaped in my case. Does it mean that this vulnerability is present only in 3.5 version?

          People

          • Assignee:
            Unassigned
            Reporter:
            Prafulla Kiran
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development