Several modules provide mechanisms for uploading files to be processed and/or attached to records. Data import, invoices, etc. are a few examples. I know in some cases the local storage of the container is used to temporarily store these files. Care should be taken to ensure that a client isn't able fill up the container storage.
A recent security audit report (internal to EBSCO) included the following advice:
To prevent a potential denial of service (DoS) attack in which a threat actor can fill up disk space, recommends implementing server-side checks of the uploaded file’s size, and potentially a quota of size used per user.
Thunderjet had done some research into limiting file upload sizes a while back (for a related, but different reason). It's probably worth reviewing what they ended up doing there to see if it's applicable. See
Vert.x: A file upload in Vert.x doesn't automatically create a file on disk. It provides chunks of the file in memory to avoid memory exhaustion: https://vertx.io/docs/vertx-core/java/#_handling_form_file_uploads . For the size limit of multi-part forms see https://vertx.io/docs/vertx-core/java/#_handling_html_forms and
The purpose of this spike is to do some investigation into which modules are vulnerable, and whether or not we can actually exploit this.
- spike findings are documented
- stories are created (and tagged w/ security) for addressing the problem in modules identified
|Module||endpoint||upload purpose||upload file limited||JIRA Ticket(s)||Inspected Class||Note|
|mod-agreements||/erm/files||external license documents, supplementary documents, eResource metadata import (json/kbart)||yes||Setting for Grails upload props|
|mod-data-export||/data-export/file-definitions||record IDs or CQL||no||
|mod-data-import||/data-import/uploadDefinitions||import of bibliografic data as well as finance data||no||DataImportImpl.java|
|mod-erm-usage||/erm-usage/files||counter reports, non-counter-reports||no||ErmUsageFilesAPI.java|
|mod-licences||/licences/files||core documents, supplementary documents||yes||Setting for Grails upload props|
|mod-saml-login||-||Identity Provider Metadata download||SamlClientLoader.java||URL is handed over to pac4j with uses org.opensaml.saml.metadata.resolver.MetadataResolver to resolve metadata from an URL
--> out of scope