Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-26746

Accidental XSRF and DoS consumption-of-space issue

XMLWordPrintable

      We experienced an unusual growth of our nonspaced attachments that appears to be a DoS vunerability both in an accidental way (with a workaround) and intentional (not easily worked around). This is under Confluence 4.0, but appears to probably apply to 4.3.1 as well.

      It appears the growing nonspaced attachment area is due to anonymous (or an authenticated local crawler such as GSA) having limited edit access and therefore having the Copy option appear in the Tools menu. The Copy page options is a standard link rather than a form POST and is therefore followed, and Confluence will then copy the page into a draft including all the attachments. This can quickly result in hundreds of copies of each document and attachment (a copy every time the crawler hits it).

      This also seems to be a Denial of Service vulnerability even if it's not editable (so the link does not appear), as synthesizing the edit link based off page metadata still creates the draft copy in the database and on disk but just warns it can't be saved. There does not appear to be an obvious way to prevent this from happening. The drafts appear to stay around for at least a month if not longer.

      I can confirm this on a local 4.0 install, but it appears to at least be possible to open the edit page on a 4.3.1 install (https://confluence.atlassian.com/pages/copypage.action?idOfPageToCopy=204049164&spaceKey=SUPPORT in a fresh Chrome Incognito session).

      This appears to have been reported as an XSS vulnerability and supposedly fixed in 2.7.3 (CONF-11027), but apparently this regressed with some update as no key is required for copypage.action.

      However even with an XSRFXSS prevention key the anonymous (default demonstration space) or authenticated (internal) crawler issue would still be an issue with drafts living a month or more, and possibly on the view-only side if the key was not short lived and or tied to only sessions with edit access.

            [CONFSERVER-26746] Accidental XSRF and DoS consumption-of-space issue

            Petro Semeniuk (Inactive) added a comment -

            There is still minor issue with visibility - https://jira.atlassian.com/browse/CONF-31749 raised.

            Petro Semeniuk (Inactive) added a comment - There is still minor issue with visibility - https://jira.atlassian.com/browse/CONF-31749 raised.

            Jeremy Mooney added a comment -

            Oops, you're correct. I stumbled on that other bug when searching and must have gotten stuck in the wrong mindset. Sorry about that. I've edited the description and removed the link to the prior issue.

            Jeremy Mooney added a comment - Oops, you're correct. I stumbled on that other bug when searching and must have gotten stuck in the wrong mindset. Sorry about that. I've edited the description and removed the link to the prior issue.

            David Black added a comment - - edited

            jmooneybethel the issue you have linked to is an issue about XSS (Cross-site scripting)[0]. However, unless I am mistaken I believe that you are referring to a XSRF(Cross-site request forgery)[1] flaw in this issue.

            [0] http://en.wikipedia.org/wiki/Cross-site_scripting
            [1] http://en.wikipedia.org/wiki/Cross-site_request_forgery

            David Black added a comment - - edited jmooneybethel the issue you have linked to is an issue about XSS (Cross-site scripting) [0] . However, unless I am mistaken I believe that you are referring to a XSRF(Cross-site request forgery) [1] flaw in this issue. [0] http://en.wikipedia.org/wiki/Cross-site_scripting [1] http://en.wikipedia.org/wiki/Cross-site_request_forgery

            Jeremy Mooney added a comment -

            I have not confirmed this was actually fixed for copypage.action in 2.7.3. docopypage.action does seem to still have the protection CONF-11027 added.

            Jeremy Mooney added a comment - I have not confirmed this was actually fixed for copypage.action in 2.7.3. docopypage.action does seem to still have the protection CONF-11027 added.

              psemeniuk Petro Semeniuk (Inactive)
              8c9275eeb659 Jeremy Mooney
              Affected customers:
              0 This affects my team
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: