• Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Minor Minor
    • core

      Jenkins 1.532.2 sets X-Frame-Options to sameorigin |https://github.com/cloudbees/hudson/commit/16931bd7bf7560e26ef98328b8e95e803d0e90f6]. While this prevents attacks via frame embedding, it also prevents any desirable embedding of Jenkins in a frame.

      This should be configurable "somehow." Either via an extension point, or allowing PageDecorators to set the header property by changing the order of layout.jelly.

          [JENKINS-21881] Make X-Frame-Options configurable

          Ryan Campbell created issue -
          Jesse Glick made changes -
          Labels Original: lts-candidate New: api lts-candidate security
          Jesse Glick made changes -
          Link New: This issue is duplicated by JENKINS-21842 [ JENKINS-21842 ]

          Jesse Glick added a comment -

          Jesse Glick added a comment - Need to check whether https://github.com/jenkinsci/xframe-filter-plugin/blob/master/src/main/resources/org/jenkins/ci/plugins/xframe_filter/XFrameFilterPageDecorator/httpHeaders.jelly works, or could be made to work.
          Jesse Glick made changes -
          Link New: This issue is blocking SECURITY-80 [ SECURITY-80 ]

          Code changed in jenkins
          User: Jesse Glick
          Path:
          pom.xml
          http://jenkins-ci.org/commit/xframe-filter-plugin/ba9635dbb1f3ce8a64ded546a4fc1c81199d3191
          Log:
          Updating to 1.532.2 so that SECURITY-80 / JENKINS-21881 can be tested.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: pom.xml http://jenkins-ci.org/commit/xframe-filter-plugin/ba9635dbb1f3ce8a64ded546a4fc1c81199d3191 Log: Updating to 1.532.2 so that SECURITY-80 / JENKINS-21881 can be tested.
          Jesse Glick made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Jesse Glick added a comment -

          http://jenkins-ci.org/commit/xframe-filter-plugin/bce246d5f2b8bb38d3c7f9784a13e80746f46c88 allows this plugin to override the X-Frame-Options header. So you could set it to ALLOW-FROM …URI… (not interpreted by all browsers), or maybe just set it to blank (TBD what that does).

          Jesse Glick added a comment - http://jenkins-ci.org/commit/xframe-filter-plugin/bce246d5f2b8bb38d3c7f9784a13e80746f46c88 allows this plugin to override the X-Frame-Options header. So you could set it to ALLOW-FROM …URI… (not interpreted by all browsers), or maybe just set it to blank (TBD what that does).

          Reynald Borer added a comment -

          As Jesse said, setting the header to ALLOW-FROM URI is not supported by all browsers (at least Chrome and Safari does not support it), so I think a better option would be to have a way to disable this header in core directly instead, like the CSRF prevention.

          Reynald Borer added a comment - As Jesse said, setting the header to ALLOW-FROM URI is not supported by all browsers (at least Chrome and Safari does not support it), so I think a better option would be to have a way to disable this header in core directly instead, like the CSRF prevention.

          Jesse Glick added a comment -

          @rborer @npfistner have you tried using (a snapshot of) the XFrame Filter plugin and just setting the header to blank (the empty string)? This causes Jenkins to send the header but with a blank value. If that is handled the same as an unset header by major browsers then this would be the easiest option.

          Otherwise I think we need an extension point in core with matching GlobalSecurityConfiguration UI with two implementations in core: current SAMEORIGIN as default, and no header with a warning about resulting vulnerabilities; the XFrame Filter plugin would offer a third implementation: a customizable header, and perhaps in the future the possibility to adjust the header dynamically according to User-Agent and/or Referer.

          Jesse Glick added a comment - @rborer @npfistner have you tried using (a snapshot of) the XFrame Filter plugin and just setting the header to blank (the empty string)? This causes Jenkins to send the header but with a blank value. If that is handled the same as an unset header by major browsers then this would be the easiest option. Otherwise I think we need an extension point in core with matching GlobalSecurityConfiguration UI with two implementations in core: current SAMEORIGIN as default, and no header with a warning about resulting vulnerabilities; the XFrame Filter plugin would offer a third implementation: a customizable header, and perhaps in the future the possibility to adjust the header dynamically according to User-Agent and/or Referer .

            danielbeck Daniel Beck
            recampbell Ryan Campbell
            Votes:
            7 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: