Encrypted HTTP Multipart Upload
This implementation is designed to be transparent to the caller. Keys are ephemeral and are generated on the fly, so encryption "just works" without you needing to do anything.
FileItem is garbage collected, the key is lost and any temp data becomes unrecoverable
(that's a good thing).
The purpose of this implementation is to make it trivial to ensure uploaded data are not written to disk in the clear.
For more discussion, see the Apache Commons FileUpload Jira: https://issues.apache.org/jira/browse/FILEUPLOAD-119
Encryption is transparent and you should need to make no change to your code, providing you stick to the
<dependency> <groupId>com.github.davidcarboni</groupId> <artifactId>encrypted-file-upload</artifactId> <version>2.0.1</version> </dependency>
// Create a factory for disk-based file items FileItemFactory factory = new EncryptedFileItemFactory(); // Create a new file upload handler ServletFileUpload upload = new ServletFileUpload(factory); // Parse the request List<FileItem> items = upload.parseRequest(request);
For more on FileUpload usage, see: https://commons.apache.org/proper/commons-fileupload/using.html
s less of a need to call factory.setRepository(...)`
because content written to disk is encrypted.
If you rely on the additional method
getStoreLocation() provided by the
implementation, you'll need to alter your code to use
The reason for this is that the raw temp file is encrypted: the content is meaningless.
Directly accessing this file (for example to move it rather than copy it)
would lead to unexpected results (i.e. a scrambled file).
getStoreLocation() method is not provided to help you avoid this happening unintentionally.
A note on how these classes have been tested.
The Commons FileUpload test suite has been copied
into this project in its entirety.
It's then been tweaked just enough to point the tests
This ensures that these implementations pass the same
standard of tests as the implementations in FileUpload.
Encryption is provided by your standard JCE providers, via the Cryptolite library.
Data are encrypted using AES-128 in Counter (CTR) mode by default. This should ensure compatibility with the majority of JVMs. If your JVM is configured for unlimited strength cryptography then larger encryption keys (AES-256) will be generated automatically.
If you would like to look in detail at the encryption code, feel free to inspect, copy or replace the JCE code from Cryptolite.
Encryption keys are generated at random and held in memory when the above classes are instantiated. Keys are lost when the objects are garbage-collected.
Strictly speaking, no security solution is perfect. However, these classes provide specific risk reduction, relative to working with cleartext temp files.
If this is something you need then this implementation is for you.