Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-28965

Help text for MSIE workaround is confusing / inaccurate since 5.0.6

XMLWordPrintable

    • 5
    • Severity 3 - Minor
    • Hide
      Atlassian Update – 06 December 2017

      Hi everyone,

      We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to resolve it as Time Out.

      Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Jira team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Atlassian Bugfix Policy for more details.

      We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication.
      Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.
      Thank you,
      Ignat Alexeyenko
      Jira Bugmaster

      Show
      Atlassian Update – 06 December 2017 Hi everyone, We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to resolve it as Time Out . Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Jira team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Atlassian Bugfix Policy for more details. We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments. Thank you, Ignat Alexeyenko Jira Bugmaster

      See the attachment ...

      This text implies that the workaround mode is only applied when the user's browser is MSIE. While part of the code that enforces it does indeed check the browser's user agent, JRA-20915 and JRA-28331 changed the enforcement of it such that the wiki renderer is instructed not to inline embedded objects at all, regardless of the browser setting, when in "workaround" mode.

      Based on conversations with several people, this change in behaviour is entirely intentional, so we need to update the descriptions for this setting (as well as any related documentation) so it is clear what the enforcement does and that it applies to all browsers.

      Actual behaviour in 5.0.6+:

      • Secure - No embedded content is rendered, whether it's an image or an "object" (flash, quicktime, sounds, etc.)
      • Insecure - All content is rendered.
      • Workaround - Embedded images are rendered, but "objects" are not.

        1. MSIE_Workaround_Text.png
          MSIE_Workaround_Text.png
          25 kB

            [JRASERVER-28965] Help text for MSIE workaround is confusing / inaccurate since 5.0.6

            Eric Dalgliesh added a comment -

            Any reason why we should keep insecure mode?

            I assume people use it to stick videos, flash, etc into their pages.

            Eric Dalgliesh added a comment - Any reason why we should keep insecure mode? I assume people use it to stick videos, flash, etc into their pages.

            Luis Miranda (Inactive) added a comment -

            this default does more than just workaround issues in IE it also uses a blacklist of file extensions and content-types which are 'executable'

            Code inspection shows that the "isExecutableContent" check happens in both secure and workaround mode. The only case when it doesn't happen is "insecure" more.

            Any reason why we should keep insecure mode?

            Luis Miranda (Inactive) added a comment - this default does more than just workaround issues in IE it also uses a blacklist of file extensions and content-types which are 'executable' Code inspection shows that the "isExecutableContent" check happens in both secure and workaround mode. The only case when it doesn't happen is "insecure" more. Any reason why we should keep insecure mode?

            David Black added a comment -

            Copying my comment from JRA-28879 here (as per request):

            It would might the "Internet Explorer MIME Sniffing Security Hole Workaround Policy" configuration option meaningless and so there's the possibility of removing that now as well. (Update: after talking to Eric we've decided to move that work to another Story and make it master-only.)

            You really don't want to do that. Actually the wording of this configuration option isn't so great. The JIRA default is to "workaround" security (xss) issues in internet explorer. However, this default does more than just workaround issues in IE it also uses a blacklist of file extensions and content-types which are 'executable' (e.g. html in the browser) to be send with a http content-disposition header value of 'attachment' and not 'inline' in all browsers.

            David Black added a comment - Copying my comment from JRA-28879 here (as per request): It would might the "Internet Explorer MIME Sniffing Security Hole Workaround Policy" configuration option meaningless and so there's the possibility of removing that now as well. (Update: after talking to Eric we've decided to move that work to another Story and make it master-only.) You really don't want to do that. Actually the wording of this configuration option isn't so great. The JIRA default is to "workaround" security (xss) issues in internet explorer. However, this default does more than just workaround issues in IE it also uses a blacklist of file extensions and content-types which are 'executable' (e.g. html in the browser) to be send with a http content-disposition header value of 'attachment' and not 'inline' in all browsers.

            Eric Dalgliesh added a comment -

            As per https://jira.atlassian.com/browse/JRA-28879?focusedCommentId=326902&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-326902 we need to check the defaults and see if there's any extra behaviour associated with the "workaround" policy. Perhaps the workaround middle policy should remain but be reworded in the UI. We may be able to remove some of the IE-specific stuff from it, but dblack reckons that it provides useful functionality for security in all browsers.

            Eric Dalgliesh added a comment - As per https://jira.atlassian.com/browse/JRA-28879?focusedCommentId=326902&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-326902 we need to check the defaults and see if there's any extra behaviour associated with the "workaround" policy. Perhaps the workaround middle policy should remain but be reworded in the UI. We may be able to remove some of the IE-specific stuff from it, but dblack reckons that it provides useful functionality for security in all browsers.

            Justus Pendleton (Inactive) added a comment -

            That entire setting and its related behaviour hasn't really been thought about in several years AFAIK. The behaviour of supported browsers has changed, they offer new precautionary headers, etc, etc. i.e. we need to perform some investigation to see if changing the text is the only relevant work.

            Justus Pendleton (Inactive) added a comment - That entire setting and its related behaviour hasn't really been thought about in several years AFAIK. The behaviour of supported browsers has changed, they offer new precautionary headers, etc, etc. i.e. we need to perform some investigation to see if changing the text is the only relevant work.

              Unassigned Unassigned
              cfuller crf
              Affected customers:
              0 This affects my team
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: