1

After analyzing my Android application with a security tool, it has detected a high level vulnerability "File unsafe delete check". I have investigated about this, and it seems that the problem is that the application uses "file.delete()".

That function is considered unsafe because data could theoretically be retrieved with a tool that scans all the storage device. So, if that way of deleting is "unsafe"... what is the "safe" way to delete files in Android? (to avoid getting that "security error" that is supposedly a "high level" one). What is the proper way to delete files in Android Development?

I am getting the same security warning in 2 different applications, one made with native Java and the other one with Xamarin Forms. Thank you very much!

androto
  • 21
  • 2

3 Answers3

2

what is the "safe" way to delete files in Android?

There is none for the vast majority of Android devices. You use delete() on File.

That function is considered unsafe because data could theoretically be retrieved with a tool that scans all the storage device

If the Android device happens to use a classic hard drive (spinning magnetic media), you can overwrite the data before deleting it. On any sort of flash media, that will be ineffective, as the physical location where the data is written can vary with each write operation ("wear leveling").

So, this really boils down to your objective:

  • If you feel that the user will be harmed if this data is available to be read, store it encrypted with a user-supplied passphrase.

  • If you are simply trying to avoid this warning, ask the developers of this "security tool" what they are expecting you to do. Or, find a better tool.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
0

This is not an Android specific issue. It has to do with how file systems work, and the physical storage media it self.

When you delete a file, regardless of API, what is actually deleted is the record in the files table.

The actual data on disk or flash storage remains.

There is a method for secure deletion: Before deleting the file, overwrite its contents with garbage or zeros several times.

But, this method only works for magnetic media such as hard disks. Android devices use NAND flash for storage.

Because the number of writes a NAND chip can take before it fails is a lot less than that of magnetic memory, these chips usually come with a mechanism that spreads out the write commands.

What this means is that even if you try to write random data or zeros over your file, there is no guarantee the actual data will be overwritten. The writes may go to a different sector to avoid wear.

So, on one hand, for flash storage it is enough to overwrite the file once, but on the other hand, it is impossible to do correctly at application level.

If you want to make your application secure, you must make sure to store sensitive data encrypted. Then, even if someone tries to read the raw storage, they wouldn't be able to recover the data.

Don't store user credentials (like passwords) in regular files on Android. Use Android accounts API and let the OS manage security.

If you still need file storage but want to protect the data, encrypt it in memory and then write to file.

Lev M.
  • 6,088
  • 1
  • 10
  • 23
  • It is more than "there is no guarantee the actual data will be overwritten", the data will not be overwritten. This is because what really happens in a write is an entire block of NAND (around 128KB) will be erased and then it will be filled with the new data and the surrounding data from the old block, Then a compare will be executed to verify write was successful and the old block will be return ed to the free block book without being erased. The reason for not erasing is because erasing consumes a lot of power. – zaph Nov 10 '18 at 21:25
  • cont: There are sone NAND flash controllers that will guarantee erasing of the old block. As an example Apple has a portion of Flash memory that does this to use with security such as key storage. – zaph Nov 10 '18 at 21:38
0

As said by the other answers the first thing to consider under a theoretical point of view is if there is really a need to store any sensitive information in files to be kept on customer side

If this is really the case, encryption is the real way to guarantee proper security. Files would be protected not only against the recovery after deletion but also during their known life on the device

That said, in the case of a vulnerability assessment - i.e. a static analysis of the code - it would not be immediate to detect that you are calling for a deletion [via file.delete()] of encrypted files. Or maybe you are just calling the deletion of files with nothing to hide

In both these cases the found vulnerability would just be a false positive. Which is part of the game because you can guess that it's quite complicated for an automated tool to understand if something really "deserves" protection or not

What you can do to get rid of the vulnerability is adding the logic to empty the files before calling file.delete(). You have a sample here for this purpose. This will solve the vulnerability detection you are experiencing

Quixxi
  • 31
  • 2
  • Quixxi added logic for clearing the file with empty text but it dosn't solve the purpose, am still getting the same vulnerability – livemaker Jun 29 '20 at 07:33