Is AEM author vulnerable to OWASP Unrestricted File Upload

[alexandreg50738]

Hello,
I was reading about the OWASP Top Ten and was wondering if the AEM Author is vulnerable to the Unrestricted File Upload vulnerability.
Here is my understanding: Taking into account that in AEM Author we have the DAM file upload, we have here a possible candidate for an OWASP Unrestricted File Upload. But since the access to the DAM file upload is restricted to trusted users, although the only possible prevention to this is the mime types whitelisting in OSGi Web Console, should this still be considered an Unrestricted File Upload vulnerability without other more advanced checkings (i.e. file upload frequency, file magic number checking)?

[hamidk92094312]

You may want to check the following document:

OWASP Top 10

Note: I dont see Unrestricted File Upload listed in OWASP Top Ten

[alexandreg50738]

You are right regarding the unrestricted file upload not being listed in the OWASP Top Ten but I would like to know if AEM mitigates this vulnerability

[hamidk92094312]

Based on CVE reports for AEM security vulnerabilities, AEM should not be vulnerable to unrestricted file upload

https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-33138/Adobe-Experience-Manager...

[Jörg_Hoh]

You mean the "problem", that every authenticated user with write access to /content/dam can upload binary files with not that much control, what actually is uploaded?

Is that an actual vulnerability? And if it's a vulnerability, how would you prevent it without removing the ability to upload binaries alltogether?

[alexandreg50738]

Yes, the case in which an authenticated user can write anything to /content/dam. According to the OWASP https://www.owasp.org/index.php/Unrestricted_File_Upload this is considered a vulnerability. But since just authenticated users can upload files I was wondering if it it still considered a vulnerability.

Regarding the countermeasure for that issue would be to have a processor in the sling request filter chain to handle the file upload checking, having then a way to check the mimetype if its allowed, if the file magic number is the same as in the mimetype and other validations that may be relevant

[Jörg_Hoh]

If a user could not upload binary data to a Digital Asset Management system, what would be the purpose of this system then? You could use the same argument with Dropbox or any other storage service.

If I understand the linked OWASP page correctly, the biggest issue with the upload is the case that this binary might get executed on the server. And from what I know and understand, AEM is not affected by such a problem.

[alexandreg50738]

A user can always upload binary data to DAM. The thing here is that it would be needed to have a way to check the file magic number to guarantee that it is according to a specific file types whitelist. Another thing that could be prevented is having a denial of service because of having a user uploading many big files in a time window

[Jörg_Hoh]

I agree, that there could be many checks and best practices to reduce potential risk. But in any way, this specific OWASP issue does not cover them, but adresses mainly the issue of (accidental or potential) execution of the uploaded binaries. Everything else is out of scope of this issue.