How to handle properly temporary files?

Question

Problem: I have a web api which expose a method UploadFile, which will upload a file from a client to a specific directory of the server. The piece of code that handle the request and do the upload is the following:

var boundary = MultipartRequestHelper.GetBoundary(MediaTypeHeaderValue.Parse(Request.ContentType), _defaultFormOptions.MultipartBoundaryLengthLimit);

var reader = new MultipartReader(boundary, HttpContext.Request.Body);

try
{
    // Read the form data.
    var section = await reader.ReadNextSectionAsync();

    // This illustrates how to get the file names.
    while (section != null)
    {
        var hasContentDispositionHeader = ContentDispositionHeaderValue.TryParse(section.ContentDisposition, out ContentDispositionHeaderValue contentDisposition);
        if (hasContentDispositionHeader)
        {

            if (MultipartRequestHelper.HasFileContentDisposition(contentDisposition))
            {
                targetFilePath = Path.Combine(root, contentDisposition.FileName.ToString());
                using (var targetStream = System.IO.File.Create(targetFilePath))
                {
                    await section.Body.CopyToAsync(targetStream);

                    //_logger.LogInformation($"Copied the uploaded file '{targetFilePath}'");
                }
            }

I always calledthis method using the following statement:

bool res = await importClient.UploadFileAsync(filePath);

where UploadFileAsync (which is on the client) build the request in this way:

var requestContent = new MultipartFormDataContent();
var array = File.ReadAllBytes(filePath);
var fileContent = new ByteArrayContent(array);
fileContent.Headers.ContentType =  MediaTypeHeaderValue.Parse("application/octet-stream");
requestContent.Add(fileContent, "file", Path.GetFileName(filePath));

As you can see, this method expect a file name/path to work, this means that the file must "exist" somewhere in the client machine. I've used this method without any problem until now. I have a very specific case in which i need to upload something needed on the server that the user don't want to save on his client.

Possible solutions:

• The first thing that i thought was to manually create a file in the client, and after the upload delete it. However I'm not very happy with this solution cause i need to handle everything manually

• I can use the System.IO.Path.GetTempFileName() method, which will create a file in the temporary directory, but i'm not quite sure how the cancellation of the files is handled

• I can use the TempFileCollection, but it seems more or less a mix of the previous point. I can technically create this collection in a using statement to get rid of it when the upload is done

I'm inexperienced about these topics, so I'm not sure which solution could fit best this scenario

My requirements are that i need to be 100% sure that the file is deleted after the upload is done, and i would like the solution to be "async friendly", i.e. i need the whole process to keep going without problems.

EDIT: I see a little bit of confusion. My problem is not how to handle the files on the server. That part is not a problem. I need to handle "temporary" files on the client.

Answer 1

Once you write something on the disk you can't be 100% that you will able to delete it. Moreover, even if you delete the file, you can't be sure that file can't be recovered.

So you have to ask why I need to delete the file. If it contains some secret, keep it in memory. If you can't fit the file into memory, write it encrypted on the disk and keep only key in the memory.

If you relax 100% to 99%, I would go for creating a file with Path.GetTempFileName and deleting it in finally block.

If 99% is not enough but 99.98% is, I would store names of created temporary files in persistent storage and regularly check if they are deleted.

Answer 2

For completition i'm writing the solution i used based on the suggestions i received here. Also the filename written as i did grant that statistically you won't have 2 temporary file with the same name

 try
 {
     string file = System.IO.Path.GetTempPath() + Guid.NewGuid().ToString() + ".xml";
     tempFile = Path.GetFileName(file);
     using (FileStream fs = new FileStream(file, FileMode.Create, FileAccess.Write, FileShare.None))
     {
         XmlSerializer serializer = new XmlSerializer(typeof(FileTemplate));
         serializer.Serialize(fs, w.Template);
     }

 }
 catch(Exception ex)
 {

     logger.Error(ex.Message);
     //...
 }
 finally
 {
     //.... do stuff
     File.Delete(tempFile );
 }

Answer 3

You clearly shouldn't be using a file, in fact you don't want your data to ever leave RAM. You need to use "secure" memory storage so that the data is "guaranteed" to be pinned to physical RAM, untouched by the garbage collector, "never" paged out to swap. I use the quotes, because all those terms are somewhat misleading: the implementation isn't secure in absolute sense, it's just more secure than writing stuff to a disk file. Absolute security is impossible.

There are no common mechanisms that guarantee deletion of anything: the machine could "die" at any point between the writing of the data to the file, and whatever deletion operation you'd use to wipe the file "clean". Then you have no guarantee that e.g. the SSD or the hard drive won't duplicate the data should e.g. a sector become bad and need to be reallocated. You seem to wish to deal with several layers of underdocumented and complex (and often subtly buggy) layers of software when you talk about files:

1. The firmware in the storage device controller.
2. The device driver for the storage device.
3. The virtual memory system.
4. The filesystem driver.
5. The virtual filesystem layer (present in most OSes).
6. The .net runtime (and possibly the C runtime, depending on implementation).

By using a file you're making a bet that all those layers will do exactly what you want them to do. That won't usually be the case unless you tightly control all of these layers (e.g. you deploy a purpose-made linux distribution that you audit, and you use your own flash storage firmware or use linux memory technology driver that you'd audit too).

Instead, you can limit your exposure to just the VM system and the runtime. See e.g. this answer; it's easy to use:

using (var secret = new SecureArray<byte>(secretLength))
{
    DoSomethingSecret(secret.Buffer);
}

SecureArray makes it likely that secret.Buffer stays in RAM - but you should audit that code as well, since, after all, you need it to do what it does, with your reputation possibly at stake, or legal liability, etc.

A simple test that can give you some peace of mind would involve a small test application that writes a short pseudorandom sequence to secret.Buffer, and then sleeps. Let this run in the background for a few days as you use your computer, then forcibly power it down (on a desktop: turn the on-off switch on the power supply to "off" position). Then boot up from a linux live CD, and run a search for some chunk of the pseudorandom sequence on the raw disk device. The expected outcome is that no identifiable part of the sequence has leaked to disk (say nothing larger than 48-64 bits). Even then you can't be totally sure, but this will thwart the majority of attempts at recovering the information...

...until someone takes the customer's system, dumps liquid nitrogen on the RAM sticks, shuts down the power, then transfers RAM to a readout device you can put together for

...or until they get malware on the system where the software runs, and it helpfully streams out RAM contents over internet, because why not.

...or until someone injects their certificate into the trust root on just one client machine, and MITM-s all the data elsewhere on the client's network.

And so on. It's all a tradeoff: how sure you wish to be that the data doesn't leak? I suggest getting the exact requirements from the customer in writing, and they must agree that they understand that it's not possible to be completely sure.