[
https://issues.apache.org/jira/browse/FILEUPLOAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474046#comment-16474046
]
David Carboni commented on FILEUPLOAD-119:
------------------------------------------
Hi Jochen, thanks for the comment.
Strictly speaking I agree. The focus of fileupload is parsing multipart
uploads. The content being handled is the user's (i.e the server-side
application's) responsibility. From this perspective it's clear-cut that
encryption is not a FileUpload feature.
I've set out my thinking below, based on the progress of encryption on the Web,
and on parallels that have emerged since this feature was first raised. I hope
this provides a clear, thoughtful picture and I'd welcome your thoughts.
This thinking is what prompted me to create an "implicit encryption"
implementation, which I used in delivering the public-facing service of a
medium-sized UK government organisation dealing in market-moving economic data,
where I (understandably) needed to satisfy demanding security constraints.
Here's where I think there are areas worth considering:
* FileUpload is accepting and processing data "on behalf of" a consuming
application and processing uploads internally. Uploads ** might be written to
disk, for an indefinite period, and could be accessible to other user accounts
on the machine. The caller needs to go to some length to manage this (setting a
repository location with appropriate OS permissions, setting a
FileCleaningTracker, or explicitly deleting uploads). For the duration that
FileUpload accepts and holds data, it would seem there's a "duty of care"
towards the caller, especially where the caller may not be fully aware of these
settings (and may not have access to the underlying OS).
* As a parallel, I'm thinking of AWS EBS or S3. It's not _strictly_ the
storage provider's responsibility to encrypt content - users really should
encrypt data themselves. However the feature is beneficial and facilitates
solutions with reduced security risk that minimise the effort required on the
part of the user.
Unpacking this thinking, whilst a user "could" implement encryption, there are
reasons why a user won't, or shouldn't have to:
* What happens behind the FileItem interface, whilst data sit inside the
implementation, ideally shouldn't concern the user (or worry their security
assurance team).
* User convenience (e.g. transparent encryption, as with AWS or https)
dramatically reduces friction / barrier to (good) implementation and enables
solutions to be more secure "by default".
* Creating a Cipher[Input|Output]Stream requires significantly more work than
wrapping an existing stream (as with say Buffered[Input|Output]Stream). It
requires acquiring an encryption key (of the right type and length), acquiring
and initialising a Cipher (of the right algorithm and mode, and introducing a
suitable initialisation vector) before the stream class can be instantiated.
Using a cipher stream classes means handling half a dozen checked exceptions
(NoSuchAlgorithmException, NoSuchPaddingException,
InvalidAlgorithmParameterException, InvalidKeyException,
IllegalBlockSizeException, BadPaddingException). This makes for heavy-going
code to handle a file upload.
* Most developers know implementing an encryption algorithm is unacceptable,
but even correct use of encryption primitives from a trusted library is
non-trivial (and using JCE adds complication on top of this). The variety of
primitives, algorithms, modes, key lengths, right down to the need for key
management and secure random number generation, means "good" encryption remains
hard for most - and few will be allowed the time to get it right (in my case I
got lucky!).
* Encryption that doesn't require user action (or behaviour change) and uses
ephemeral keys (so avoiding key management) provides a very low barrier to use.
The Web has come a long way since 2006 and encryption is now the norm online
(I'm thinking of advances like Letsencrypt, Chrome frowning on non-https sites,
and increased business awareness data breaches). I've had to deal with an
enterprise security team who weren't happy to accept data not encrypted at
rest, even where underlying storage was encrypted, because they weren't happy
to accept the risk of administrative accounts on the machine.
I hope this is constructive and would be interested to hear what you think.
> The encryption & decryption of uploaded file
> --------------------------------------------
>
> Key: FILEUPLOAD-119
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-119
> Project: Commons FileUpload
> Issue Type: New Feature
> Environment: Windows/Linux
> Reporter: inderjeet
> Priority: Critical
>
> Hi,
> Can we upload the file in the encypted format and later decrypt it to show
> the file so that noone can directly open the file from the disk space (hard
> disk) where i have uploaded the file usinf fileUpload functionality. This is
> the major concern for our project ?
> Is there any external library which can do this for us even just after we
> upload the file through this API ?
> Thanks & Regards
> Inderjeet
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
