Skip to content

Conversation

@Sigmonia
Copy link
Contributor

@Sigmonia Sigmonia commented Nov 11, 2024

Rationale

Secure Issue 51524: Allowlist for acceptable types of file upload

Related PRs

Changes

  • updated shared jsps
  • Add allow list
  • and extension checker to file uploads

@Sigmonia Sigmonia self-assigned this Nov 11, 2024
assertNotNull("Matched unlist extension", checkExtension("my test.notListed", mockProps));
assertNotNull("Combined multiple extension matched incorrectly", checkExtension("multi.a_v.tar", mockProps));
assertNotNull("Multi-multi extension matched unexpectedly", checkExtension("multi.not.tar.gz", mockProps));
assertNotNull("No extension matched unexpectedly", checkExtension("No extension", mockProps));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't considered files with no extension. I guess it's OK to reject them all at this point.


if (FileUtil.isAllowedFileName(name) != null)
{
throw new IOException("The file extension is not allowed.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may reject the name unrelated to the exception. Let's use the message this call returns instead of hard-coding the error message

@Sigmonia Sigmonia force-pushed the 24.11_fb_fileExtensions branch from 3a252ce to ef580e1 Compare November 14, 2024 21:21
if (appProps.getAllowedExtensions().isEmpty())
return null;

if (extensionChecker == null)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When does this get cleared? It seems very sticky.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It only gets changed in setExtensionChecker which is called when the WritableAppProps.setAllowedFileExtensions is called when the new Allow List prop is saved or when the server is starting up

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. The pattern confused me. I would have expected a getExtensionCheck() that wrapped the null check.

@labkey-matthewb
Copy link
Contributor

Do we want to allow folder names to have "." in them? Disallowing doesn't seem to be related to the original goal of the feature.

String notAllowedMsg = FileUtil.isAllowedFileName(name);
if (StringUtils.isNotBlank(notAllowedMsg))
{
throw new IOException(notAllowedMsg);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

throw DavException in the dav controller to get the file browser to display an expected UI. Maybe use 409 SC_CONFLICT? or 406 (SC_NOT_ACCEPTABLE)

- fix regex quoting
- modified checker methods to be testable

adjusted description text
- Move isInvalidFilenameBlocked check
- Subclass Multipart Resolver so we can more easily check the file extension
- fix typos and messaging
Updated error message read the text passed
@Sigmonia Sigmonia force-pushed the 24.11_fb_fileExtensions branch from 5bd71ea to b8ea9af Compare November 19, 2024 22:21
@Sigmonia Sigmonia merged commit f8c2495 into release24.11-SNAPSHOT Nov 20, 2024
2 of 10 checks passed
@Sigmonia Sigmonia deleted the 24.11_fb_fileExtensions branch November 20, 2024 00:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants