Details
-
Task
-
Status: Open (View Workflow)
-
P3
-
Resolution: Unresolved
-
None
-
-
None
Description
Overview
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
- https://issues.folio.org/browse/MODINVOICE-142
- https://issues.folio.org/browse/MODINVOICE-124
- https://wiki.folio.org/display/FOLIJET/Spike%3A+Investigate+limiting+document+size+on+upload
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 RMB-856.
The purpose of this spike is to do some investigation into which modules are vulnerable, and whether or not we can actually exploit this.
Acceptance Criteria
- spike findings are documented
- stories are created (and tagged w/ security) for addressing the problem in modules identified
Investigation on modules with upload capabilties
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 | |
DataExportImplFileDefinitionImpl.java | |
mod-data-import | /data-import/uploadDefinitions | import of bibliografic data as well as finance data | no | MODDATAIMP-608 | DataImportImpl.java | |
mod-erm-usage | /erm-usage/files | counter reports, non-counter-reports | no | MODEUS-139 | ErmUsageFilesAPI.java | |
mod-finc-config | no | UIFC-262 | FincSelectFilesAPI.java FincConfigFilesAPI.java |
|||
mod-invoice | /invoice/invoices | invoice documents | yes | InvoicesImpl.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 |
TestRail: Results
Attachments
Issue Links
- relates to
-
FOLIO-3316 File upload size configuration
-
- Open
-
-
FOLIO-3522 Limit file upload size in Stripes nginx
-
- Closed
-
-
MODEUS-139 Limit file upload size
-
- Open
-
-
MODEXPS-51 Limit file upload size
-
- Closed
-
-
MODINVOICE-124 Limit document size
-
- Closed
-
-
RMB-856 Make maxFormAttributeSize configurable
-
- Closed
-
-
MDEXP-487 Spike: Limit file upload size
-
- Closed
-
-
RSRVR-114 Limit request body to 64 kb for non-streaming stuff
-
- Closed
-
-
UIFC-262 Limit file upload size
-
- Open
-
-
VERTXLIB-35 OpenAPI: OOM for any large POST/PUT
-
- Closed
-
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...