Accidental XSRF and DoS consumption-of-space issue

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.