• Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Minor Minor
    • _unsorted
    • None
    • CSP compatibility for Jenkins plugins

      Full details on the approach: https://docs.google.com/document/d/1hr_Kaf0fVWBACibpHbSYsk4RoqcHD3cBrqXxuTtWKVM (public)


      Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

      The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

      To achieve this migration with as little pain as possible, here are the proposed steps:
      1) Moving inline scripts / styles to their own file or equivalent
      2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
      3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

      The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.


      Compatibility for plugins
      https://docs.google.com/spreadsheets/d/1Jr5FpkAN-FjTd0D_VLz00Ab5iXNiCK03fUs2JR2omXQ

      Documentation on jenkins.io about how to find and adjust code
      https://www.jenkins.io/doc/developer/security/csp/

          [JENKINS-60865] CSP compatibility for Jenkins plugins

          Wadeck Follonier created issue -
          Wadeck Follonier made changes -
          Epic Child New: JENKINS-60866 [ 204240 ]
          Wadeck Follonier made changes -
          Description Original: Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts to their own file or equivalent
          2) Moving inline styles to regular css class / file
          3) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          4) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          New: Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts to their own file or equivalent
          2) Moving inline styles to regular css class / file
          3) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          4) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          Wadeck Follonier made changes -
          Description Original: Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts to their own file or equivalent
          2) Moving inline styles to regular css class / file
          3) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          4) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          New: Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts / styles to their own file or equivalent
          2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          Daniel Beck made changes -
          Link New: This issue relates to HOSTING-1103 [ HOSTING-1103 ]
          Wadeck Follonier made changes -
          Description Original: Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts / styles to their own file or equivalent
          2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          New: Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          Context

          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts / styles to their own file or equivalent
          2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          Wadeck Follonier made changes -
          Description Original: Objective of this Epic: introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          Context

          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts / styles to their own file or equivalent
          2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          New: h3. Objective
          Introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          h3. Context
          During the last years, we (Jenkins Security team) have seen a lot of Cross-Site Scripting (XSS) vulnerabilities, inside Jenkins core and also for a lot of plugins. We have put in place different kind of mechanism to enhance the protection of some of the common dangerous code location. But this kind of approach does not scale enough to cover the wide ecosystem and the numerous different ways of introducing (accidentally) XSS vulnerabilities.

          h3. What is CSP?
          The CSP information is either a header in the response or a meta tag inside the HTML that the server can return to inform the client (browser) about how to improve the security of the web page by reducing the allowed "external" location for code to be loaded from. Using this technique, the developer can decide to restrict that the JavaScript files are only accepted from the same-origin. It means for example, if you are on ci.jenkins.io, you would only be allowed to load JS files from ci.jenkins.io/xxx, like ci.jenkins.io/static/<random>/scripts/prototype.js.
          This feature has two mode of operation, either you just report the issue or you enforce the rules and thus, prevent all non-allowed files to be downloaded.

          h3. Why CSP?



          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts / styles to their own file or equivalent
          2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          Wadeck Follonier made changes -
          Description Original: h3. Objective
          Introducing the Content Security Policy ([reference|https://developer.mozilla.org/fr/docs/Web/HTTP/CSP]).

          h3. Context
          During the last years, we (Jenkins Security team) have seen a lot of Cross-Site Scripting (XSS) vulnerabilities, inside Jenkins core and also for a lot of plugins. We have put in place different kind of mechanism to enhance the protection of some of the common dangerous code location. But this kind of approach does not scale enough to cover the wide ecosystem and the numerous different ways of introducing (accidentally) XSS vulnerabilities.

          h3. What is CSP?
          The CSP information is either a header in the response or a meta tag inside the HTML that the server can return to inform the client (browser) about how to improve the security of the web page by reducing the allowed "external" location for code to be loaded from. Using this technique, the developer can decide to restrict that the JavaScript files are only accepted from the same-origin. It means for example, if you are on ci.jenkins.io, you would only be allowed to load JS files from ci.jenkins.io/xxx, like ci.jenkins.io/static/<random>/scripts/prototype.js.
          This feature has two mode of operation, either you just report the issue or you enforce the rules and thus, prevent all non-allowed files to be downloaded.

          h3. Why CSP?



          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts / styles to their own file or equivalent
          2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          New: Full details on the approach: https://docs.google.com/document/d/1hr_Kaf0fVWBACibpHbSYsk4RoqcHD3cBrqXxuTtWKVM (public)

          ----

          Without entering too much into details, to achieve a good CSP protection, we need to create a whitelist of URL that are approved (could be same-origin) for static content (CSS / JavaScript) or/and a list of whitelisted / authorized content. Adding a content (using its hash) to the whitelist has the drawback to add weight on every response.

          The advantage of that set of headers is to prevent a large number of XSS threats. The mechanism will prevent the execution of unauthorized scripts and styles.

          To achieve this migration with as little pain as possible, here are the proposed steps:
          1) Moving inline scripts / styles to their own file or equivalent
          2) Put in a place sort of a reporting / monitoring tooling inside Jenkins to know when a rule is broken
          3) Once we are sufficiently confident we have covered all the cases, enforce the rules.

          The points 1 and 2 will already help in prevent "direct" XSS where variables are injected in the code directly. That will also clean up a bit the different (and weird) ways to inject variables into JavaScript / CSS.
          Wadeck Follonier made changes -
          Epic Child New: JENKINS-66718 [ 212719 ]
          Wadeck Follonier made changes -
          Epic Child New: JENKINS-66723 [ 212725 ]
          Wadeck Follonier made changes -
          Epic Child New: JENKINS-66728 [ 212730 ]

            shlomo_dahan Shlomo
            wfollonier Wadeck Follonier
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: