IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-73212

Submitting an issue collector on a non-same origin site results in HTTP 404

      Issue Summary

      XSRF checks were added to the endpoint /rest/collectors/1.0/template/custom as part of the fix for JRASERVER-73068

      The server receives requests from the same origin, as the form page is the same origin as the form submission, thus, the XSRF HTTP header matches, which is fine.

      However for the XSRF check to succeed, the form token and cookie token sent to the server must match. The problem occurs because modern web browser (beginning Chrome 80+) do not accept the atlassian.xsrf.cookie initially sent by the server in an iframe as it is treated as cross-site and is therefore rejected. This is because the cookie does not have the Same-Site:None attribute set (see JRASERVER-70494).

      Steps to Reproduce

      1. Create a Jira 8.20.3, a sample SCRUM project, and an issue collector (custom type)
      2. Insert the sample code into a html page on the same site (for testing local, JIRA_INSTALL/atlassian-jira/static-assets/test.html is fine)
      3. Load the page (eg http://JUPITER/static-assets/test.html), and submit an issue with the collector. Note that the POST to /rest/collectors/1.0/template/custom succeeds
      4. Insert the sample code into a html page on your local machine (differing origin), and load it in your browser

      Expected Results

      The issue submission succeeds

      Actual Results

      • The POST to /rest/collectors/1.0/template/custom is rejected with HTTP 404 and body "XSRF check failed"
      • Error is presented to the client

        Oops - something went wrong...
        There was a problem submitting your feedback, likely due to the configuration of this form. You might want to contact the site owner to let them know about this issue

      When enabling Jira Admin -> System -> Logging and Profiling -> HTTP Access log (ON) -> HTTP Dump Log (ON), the response from the client can be observed in JIRA_HOME/log/atlassian-jira-http-dump.log. Observe that the client does not sent the XSRF token in the cookie, as the browser rejected storing it

      Workaround

      The following workaround will disable XSRF checks for the issue collector, which was the behaviour prior to JRASERVER-73068. This may be tolerable for you, but it's worthwhile confirming within your organisation

      Modify the reverse proxy / load balancer / WAF to add the following header to the request as it makes it's way to the Jira node:

      • Condition: Method: POST
      • Condition: Request URL: /rest/collectors/1.0/template/custom/*
      • Action: Add header: X-Atlassian-Token: no-check

      Note on fix

      We've added "SameSite=None" parameter to xsrftoken, which is on by default.
      Please note : fix works only if connection is secure, issue collector needs to access Jira through https protocol. If it is not, collector works properly only on firefox.
      Unfortunately we can't omit this restriction, because that's how cookies are handled on chrome, opera etc. and they don't allow setting SameSite=None parameter to cookies if connection is not secure.

      Note that the reverse proxy needs to allow the SameSite cookie (SameSite="none") and the secure="true" attribute needs to be present in the Tomcat connector (server.xml). This is required so that the HTTP response sets the cookie parameters correctly.

        1. image-2022-01-26-21-14-57-092.png
          image-2022-01-26-21-14-57-092.png
          305 kB
        2. image-2022-01-26-21-15-28-033.png
          image-2022-01-26-21-15-28-033.png
          599 kB
        3. image-2022-01-26-21-16-13-655.png
          image-2022-01-26-21-16-13-655.png
          29 kB
        4. image-2022-01-26-21-23-10-335.png
          image-2022-01-26-21-23-10-335.png
          18 kB
        5. image-2022-01-27-13-09-59-772.png
          image-2022-01-27-13-09-59-772.png
          71 kB
        6. notworking.har
          1.98 MB
        7. screenshot-1.png
          screenshot-1.png
          282 kB
        8. screenshot-2.png
          screenshot-2.png
          508 kB

            Loading...
            IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
            Uploaded image for project: 'Jira Data Center'
            1. Jira Data Center
            2. JRASERVER-73212

            Submitting an issue collector on a non-same origin site results in HTTP 404

                Issue Summary

                XSRF checks were added to the endpoint /rest/collectors/1.0/template/custom as part of the fix for JRASERVER-73068

                The server receives requests from the same origin, as the form page is the same origin as the form submission, thus, the XSRF HTTP header matches, which is fine.

                However for the XSRF check to succeed, the form token and cookie token sent to the server must match. The problem occurs because modern web browser (beginning Chrome 80+) do not accept the atlassian.xsrf.cookie initially sent by the server in an iframe as it is treated as cross-site and is therefore rejected. This is because the cookie does not have the Same-Site:None attribute set (see JRASERVER-70494).

                Steps to Reproduce

                1. Create a Jira 8.20.3, a sample SCRUM project, and an issue collector (custom type)
                2. Insert the sample code into a html page on the same site (for testing local, JIRA_INSTALL/atlassian-jira/static-assets/test.html is fine)
                3. Load the page (eg http://JUPITER/static-assets/test.html), and submit an issue with the collector. Note that the POST to /rest/collectors/1.0/template/custom succeeds
                4. Insert the sample code into a html page on your local machine (differing origin), and load it in your browser

                Expected Results

                The issue submission succeeds

                Actual Results

                • The POST to /rest/collectors/1.0/template/custom is rejected with HTTP 404 and body "XSRF check failed"
                • Error is presented to the client

                  Oops - something went wrong...
                  There was a problem submitting your feedback, likely due to the configuration of this form. You might want to contact the site owner to let them know about this issue

                When enabling Jira Admin -> System -> Logging and Profiling -> HTTP Access log (ON) -> HTTP Dump Log (ON), the response from the client can be observed in JIRA_HOME/log/atlassian-jira-http-dump.log. Observe that the client does not sent the XSRF token in the cookie, as the browser rejected storing it

                Workaround

                The following workaround will disable XSRF checks for the issue collector, which was the behaviour prior to JRASERVER-73068. This may be tolerable for you, but it's worthwhile confirming within your organisation

                Modify the reverse proxy / load balancer / WAF to add the following header to the request as it makes it's way to the Jira node:

                • Condition: Method: POST
                • Condition: Request URL: /rest/collectors/1.0/template/custom/*
                • Action: Add header: X-Atlassian-Token: no-check

                Note on fix

                We've added "SameSite=None" parameter to xsrftoken, which is on by default.
                Please note : fix works only if connection is secure, issue collector needs to access Jira through https protocol. If it is not, collector works properly only on firefox.
                Unfortunately we can't omit this restriction, because that's how cookies are handled on chrome, opera etc. and they don't allow setting SameSite=None parameter to cookies if connection is not secure.

                Note that the reverse proxy needs to allow the SameSite cookie (SameSite="none") and the secure="true" attribute needs to be present in the Tomcat connector (server.xml). This is required so that the HTTP response sets the cookie parameters correctly.

                  1. image-2022-01-26-21-14-57-092.png
                    image-2022-01-26-21-14-57-092.png
                    305 kB
                  2. image-2022-01-26-21-15-28-033.png
                    image-2022-01-26-21-15-28-033.png
                    599 kB
                  3. image-2022-01-26-21-16-13-655.png
                    image-2022-01-26-21-16-13-655.png
                    29 kB
                  4. image-2022-01-26-21-23-10-335.png
                    image-2022-01-26-21-23-10-335.png
                    18 kB
                  5. image-2022-01-27-13-09-59-772.png
                    image-2022-01-27-13-09-59-772.png
                    71 kB
                  6. notworking.har
                    1.98 MB
                  7. screenshot-1.png
                    screenshot-1.png
                    282 kB
                  8. screenshot-2.png
                    screenshot-2.png
                    508 kB

                        growinski@atlassian.com Greg Rowinski (Inactive)
                        allewellyn@atlassian.com Alex [Atlassian,PSE]
                        Votes:
                        78 Vote for this issue
                        Watchers:
                        118 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            growinski@atlassian.com Greg Rowinski (Inactive)
                            allewellyn@atlassian.com Alex [Atlassian,PSE]
                            Affected customers:
                            78 This affects my team
                            Watchers:
                            118 Start watching this issue

                              Created:
                              Updated:
                              Resolved: