[FOLIO-3317] Spike - investigate possible file upload vulnerability Created: 21/Oct/21  Updated: 07/Dec/22

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Hongwei Ji Assignee: Axel Dörrer
Resolution: Unresolved Votes: 0
Labels: security, security-reviewed
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-3316 File upload size configuration Open
relates to MODEUS-139 Limit file upload size Open
relates to MODINVOICE-124 Limit document size Closed
relates to MODEXPS-51 Limit file upload size Closed
relates to RMB-856 Make maxFormAttributeSize configurable Closed
relates to FOLIO-3522 Limit file upload size in Stripes nginx Closed
relates to UIFC-262 Limit file upload size Open
relates to MDEXP-487 Spike: Limit file upload size Closed
relates to RSRVR-114 Limit request body to 64 kb for non-s... Closed
relates to VERTXLIB-35 OpenAPI: OOM for any large POST/PUT Closed
Sprint:
Development Team: 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 

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 Closed .

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 MDEXP-487 Closed 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 Open FincSelectFilesAPI.java
FincConfigFilesAPI.java
 
mod-invoice /invoice/invoices invoice documents yes MODINVOICE-142 Closed
MODINVOICE-124 Closed
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

Generated at Thu Feb 08 23:27:13 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.