s1037989
commented
10 years ago Yes you're very right. Ultimately we may just drop that feature and the solution is for users to set a download count and or lower expiration date in order to have their content removed.
If we want to keep the delete function, a CAPTCHA should be added.
But my primary reason in adding the feature without protection is the knowledge that the uuid space is more than 122 unique bits or 10^36 possible sessions. And with a default expiration of 30 days likely there will never be more than 10^7 sessions active at any given time. That leaves 10^29 empty sessions in a malicious user's search space. At even 1000 delete requests per second the best anyone could achieve is 10^9 deletes per month. Therefore the odds are 1:10^20 that someone would ever delete a valid session. Pretty much fat chance. :) On Apr 24, 2014 2:51 PM, "Caleb Albers" notifications@github.com wrote:
Currently, someone could create a script (if they be so devious) that creates session IDs and automatically goes to dropzone.dev.kit.cm/$insert_session_id_here$/delete and mass deletes sessions.
We could use AJAX to implement a check to make sure that the user is clicking the button from the session page. What I mean by that is creating some sort of random key that is generated on-click that then has to be sent to the server when the delete page is visited, thus making it harder for someone to mass-delete sessions.
Maybe pose a limit on session removals per IP, else keep the files for X-amount of time as a backup before truly deleting them.
— Reply to this email directly or view it on GitHubhttps://github.com/KeystoneIT/Dropzone/issues/30 .
The information contained in this e-mail message and any attachments is confidential and is intended only for the use of the individual or entity named above. It may contain information that is privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by telephone, and destroy all copies of this message and any attachments. Thank you.
Currently, someone could create a script (if they be so devious) that creates session IDs and automatically goes to dropzone.dev.kit.cm/$insert_session_id_here$/delete and mass deletes sessions.
We could use AJAX to implement a check to make sure that the user is clicking the button from the session page. What I mean by that is creating some sort of random key that is generated on-click that then has to be sent to the server when the delete page is visited, thus making it harder for someone to mass-delete sessions.
Maybe pose a limit on session removals per IP, else keep the files for X-amount of time as a backup before truly deleting them.