Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-13982

set security-related http response headers by default

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 8.4
    • None
    • None

    Description

      Solr server should set some best practice http security response headers, to e.g. protect users of the admin ui against XSS/injection/clickjacking/etc

      • Content-Security-Policy
      • X-Content-Type-Options
      • X-XSS-Protection
      • X-Frame-Options

      Disabling inline javascript is important, so that e.g. if there is a bug then injected code doesn't get executed. Unfortunately the current admin UI dangerously relies on eval, so for now unsafe-eval must be allowed so that everything still works. This should really be cleaned up, i have the feeling as long as it works this way, that you can still execute stuff.

      Attachments

        1. SOLR-13982.patch
          2 kB
          Robert Muir

        Issue Links

          Activity

            rcmuir Robert Muir added a comment -

            Attached is an initial patch: I confirmed all parts of the admin UI work fine with it.

            rcmuir Robert Muir added a comment - Attached is an initial patch: I confirmed all parts of the admin UI work fine with it.

            Looks good, Robert. Thanks!

            Disabling inline javascript is important, so that e.g. if there is a bug then injected code doesn't get executed. Unfortunately the current admin UI dangerously relies on eval, so for now unsafe-eval must be allowed so that everything still works. This should really be cleaned up, i have the feeling as long as it works this way, that you can still execute stuff.

            How extensively do we use unsafe evaluations in the admin UI? Can we remove those functionality from the admin UI that use such evaluations?

            ichattopadhyaya Ishan Chattopadhyaya added a comment - Looks good, Robert. Thanks! Disabling inline javascript is important, so that e.g. if there is a bug then injected code doesn't get executed. Unfortunately the current admin UI dangerously relies on eval, so for now unsafe-eval must be allowed so that everything still works. This should really be cleaned up, i have the feeling as long as it works this way, that you can still execute stuff. How extensively do we use unsafe evaluations in the admin UI? Can we remove those functionality from the admin UI that use such evaluations?
            rcmuir Robert Muir added a comment -

            How extensively do we use unsafe evaluations in the admin UI? Can we remove those functionality from the admin UI that use such evaluations?

            It seems extensive: for example if you open up solr/webapp/web/index.html you see elements like this:

            <li id="environment" ng-class="environment" ng-show="showEnvironment" ng-style="environment_color !== undefined ? {'background-color': environment_color} : ''">
            

            the stuff in the ng-style attribute looks a lot like javascript code, I am afraid somehow things are organized such that javascript code can be placed in attributes like this and it gets eval'd at runtime.

            So with this patch, if i find an injection, while i may not be able to simply inject inline JS directly anymore, i can probably just encode my payload instead into an attribute like this ng-style and it will get eval'ed for me: its not gonna be that much safer until we address this crazy eval'ing.

            I don't know enough about the frameworks being used here to know if we are just using a very naive insecure framework, and it needs to be swapped out for something else, or if we are just using it in an insecure way and there is a simple fix. Either way, seems like a biggish change to fix, and we should start somewhere IMO.

            rcmuir Robert Muir added a comment - How extensively do we use unsafe evaluations in the admin UI? Can we remove those functionality from the admin UI that use such evaluations? It seems extensive: for example if you open up solr/webapp/web/index.html you see elements like this: <li id="environment" ng-class="environment" ng-show="showEnvironment" ng-style="environment_color !== undefined ? {'background-color': environment_color} : ''"> the stuff in the ng-style attribute looks a lot like javascript code, I am afraid somehow things are organized such that javascript code can be placed in attributes like this and it gets eval 'd at runtime. So with this patch, if i find an injection, while i may not be able to simply inject inline JS directly anymore, i can probably just encode my payload instead into an attribute like this ng-style and it will get eval'ed for me: its not gonna be that much safer until we address this crazy eval'ing. I don't know enough about the frameworks being used here to know if we are just using a very naive insecure framework, and it needs to be swapped out for something else, or if we are just using it in an insecure way and there is a simple fix. Either way, seems like a biggish change to fix, and we should start somewhere IMO.
            rcmuir Robert Muir added a comment -

            You can see the bad guy if you remove unsafe-eval from the CSP here, hit the admin UI, and look at browser console:

            Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”). angular.min.js:formatted:4889
            
            rcmuir Robert Muir added a comment - You can see the bad guy if you remove unsafe-eval from the CSP here, hit the admin UI, and look at browser console: Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”). angular.min.js:formatted:4889
            rcmuir Robert Muir added a comment -

            It seems the angular framework used here can be coerced into behaving securely, but I imagine all this inline stuff has to be cleaned up or precompiled or whatever: https://docs.angularjs.org/api/ng/directive/ngCsp

            rcmuir Robert Muir added a comment - It seems the angular framework used here can be coerced into behaving securely, but I imagine all this inline stuff has to be cleaned up or precompiled or whatever: https://docs.angularjs.org/api/ng/directive/ngCsp
            rcmuir Robert Muir added a comment -

            I made a followup issue to address this unsafe-eval: SOLR-13987

            I'd like for us to "get started" with something similar to the patch here. It is better than nothing!

            rcmuir Robert Muir added a comment - I made a followup issue to address this unsafe-eval : SOLR-13987 I'd like for us to "get started" with something similar to the patch here. It is better than nothing!

            Commit c8c9c1002353db3b8a4d89d21849bf67bc4f0931 in lucene-solr's branch refs/heads/master from Robert Muir
            [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8c9c10 ]

            SOLR-13982: set security-related http response headers by default

            Unfortunately, as a first start this is very weak protection against
            e.g. XSS. This is because some 'unsafe-xxx' rules must be present due
            to the insecurity of angular JS: Until SOLR-13987 is fixed, XSS & co are
            still easy.

            jira-bot ASF subversion and git services added a comment - Commit c8c9c1002353db3b8a4d89d21849bf67bc4f0931 in lucene-solr's branch refs/heads/master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8c9c10 ] SOLR-13982 : set security-related http response headers by default Unfortunately, as a first start this is very weak protection against e.g. XSS. This is because some 'unsafe-xxx' rules must be present due to the insecurity of angular JS: Until SOLR-13987 is fixed, XSS & co are still easy.

            Commit 55b77358cff29ae1ebf8d8bcab754450e14b1a0a in lucene-solr's branch refs/heads/branch_8x from Robert Muir
            [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=55b7735 ]

            SOLR-13982: set security-related http response headers by default

            Unfortunately, as a first start this is very weak protection against
            e.g. XSS. This is because some 'unsafe-xxx' rules must be present due
            to the insecurity of angular JS: Until SOLR-13987 is fixed, XSS & co are
            still easy.

            jira-bot ASF subversion and git services added a comment - Commit 55b77358cff29ae1ebf8d8bcab754450e14b1a0a in lucene-solr's branch refs/heads/branch_8x from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=55b7735 ] SOLR-13982 : set security-related http response headers by default Unfortunately, as a first start this is very weak protection against e.g. XSS. This is because some 'unsafe-xxx' rules must be present due to the insecurity of angular JS: Until SOLR-13987 is fixed, XSS & co are still easy.
            rcmuir Robert Muir added a comment -

            thanks for looking at the patch ishan! I hope we find a way to fix SOLR-13987 so that modern browser security actually works for us

            rcmuir Robert Muir added a comment - thanks for looking at the patch ishan! I hope we find a way to fix SOLR-13987 so that modern browser security actually works for us

            Commit c8c9c1002353db3b8a4d89d21849bf67bc4f0931 in lucene-solr's branch refs/heads/gradle-master from Robert Muir
            [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8c9c10 ]

            SOLR-13982: set security-related http response headers by default

            Unfortunately, as a first start this is very weak protection against
            e.g. XSS. This is because some 'unsafe-xxx' rules must be present due
            to the insecurity of angular JS: Until SOLR-13987 is fixed, XSS & co are
            still easy.

            jira-bot ASF subversion and git services added a comment - Commit c8c9c1002353db3b8a4d89d21849bf67bc4f0931 in lucene-solr's branch refs/heads/gradle-master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8c9c10 ] SOLR-13982 : set security-related http response headers by default Unfortunately, as a first start this is very weak protection against e.g. XSS. This is because some 'unsafe-xxx' rules must be present due to the insecurity of angular JS: Until SOLR-13987 is fixed, XSS & co are still easy.
            jpountz Adrien Grand added a comment -

            Closing after the 8.4.0 release.

            jpountz Adrien Grand added a comment - Closing after the 8.4.0 release.

            People

              rcmuir Robert Muir
              rcmuir Robert Muir
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: