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.

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Low Low
    • 2.2 Iteration 2, 2.2
    • 2.0
    • Crowd 2.0.0 (Build:#406 - Jul 29, 2009)
      Sun Java 1.6.0_16, JVM 14.2-b01

      Like FE-899

      Set-up is something like this:

      • SSO domain is .example.com
      • Crowd-authenticated sites are {wiki,bugs,crowd}.example.com
      • Additionally, webdav.example.com allows users to easily make test websites

      Even though webdav.example.com is configured to only allow static content, JavaScript can still steal cookies (tested with <script>document.write(document.cookie)</script>).

      Admittedly, the "correct" fix is to stick "trusted" content under a different subdomain (.secure.example.com) but that gets messy. Additionally, it's perfectly feasible to make webdav.example.com Crowd-authenticated but not wish for embedded JS to read the same cookies (this can be fixed by making webdav.example.com serve application/octet-stream, Content-Disposition: attachment and moving the "normal" server to webdav.example.net, but that's even messier).

            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.

              • Icon: Bug Bug
              • Resolution: Duplicate
              • Icon: Low Low
              • 2.2 Iteration 2, 2.2
              • 2.0
              • Crowd 2.0.0 (Build:#406 - Jul 29, 2009)
                Sun Java 1.6.0_16, JVM 14.2-b01

                Like FE-899

                Set-up is something like this:

                • SSO domain is .example.com
                • Crowd-authenticated sites are {wiki,bugs,crowd}.example.com
                • Additionally, webdav.example.com allows users to easily make test websites

                Even though webdav.example.com is configured to only allow static content, JavaScript can still steal cookies (tested with <script>document.write(document.cookie)</script>).

                Admittedly, the "correct" fix is to stick "trusted" content under a different subdomain (.secure.example.com) but that gets messy. Additionally, it's perfectly feasible to make webdav.example.com Crowd-authenticated but not wish for embedded JS to read the same cookies (this can be fixed by making webdav.example.com serve application/octet-stream, Content-Disposition: attachment and moving the "normal" server to webdav.example.net, but that's even messier).

                        psongsiritat Piyawoot Songsiritat [Atlassian]
                        0b1305f102cb T Chan
                        Affected customers:
                        2 This affects my team
                        Watchers:
                        1 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            psongsiritat Piyawoot Songsiritat [Atlassian]
                            0b1305f102cb T Chan
                            Affected customers:
                            2 Vote for this issue
                            Watchers:
                            1 Start watching this issue

                              Created:
                              Updated:
                              Resolved: