Commons FileUpload
  1. Commons FileUpload
  2. FILEUPLOAD-85

[fileupload] Use a secure delete if the file is written to the disk

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: All

      Description

      org.apache.commons.fileupload.disk.DiskFileItem just uses a simple java
      File.delete().

      Especially, when a server using fileupload is sitting in a DMZ, one would want
      it to also be physically deleted just like pgp wipe does it.

      The right place to provide such a method might be commons-io? (see COM-1710)

        Activity

        Hide
        Martin Cooper added a comment -

        People who care about security as you describe would be much better off not
        writing to the file system in the first place, or encrypting the files as they
        are written to disk. Either of these can be accomplished by implementing a
        custom FileItemFactory.

        Using a secure deletion mechanism still leaves the file wide open on the disk
        for the duration of its processing. That would be a half-hearted approach to
        security at best. Wouldn't implementing such a mechanism be more likely to lull
        people into a false sense of security?

        Show
        Martin Cooper added a comment - People who care about security as you describe would be much better off not writing to the file system in the first place, or encrypting the files as they are written to disk. Either of these can be accomplished by implementing a custom FileItemFactory. Using a secure deletion mechanism still leaves the file wide open on the disk for the duration of its processing. That would be a half-hearted approach to security at best. Wouldn't implementing such a mechanism be more likely to lull people into a false sense of security?
        Hide
        Ralf Hauser added a comment -

        martin, I certainly agree that what I propose is not the perfect solution.
        But I contend it to be without much burden on anyone (e.g. consumption of
        processing power) "a lot more secure by default".

        A lot of people get commons-fileupload.jar as part of struts or another package
        and never bother to even read any documentation about it.
        Your recommendation about even higher security achievable is certainly a good
        one, but as long http://jakarta.apache.org/commons/fileupload/customizing.html
        is rather empty, certainly only VERY FEW people are doing it.

        So, an exposure during processing time of a few (milli)seconds as opposed to
        months of residing on a disk and possibly even being found during disposal by
        totally unrelated third parties IS a difference.
        Agreed, quite some disclaimers would have to go with it, but I think for the
        little cost it incurs, it is a first step in the right direction worthwhile to
        take. (at least offer it as a configurable option)

        Show
        Ralf Hauser added a comment - martin, I certainly agree that what I propose is not the perfect solution. But I contend it to be without much burden on anyone (e.g. consumption of processing power) "a lot more secure by default". A lot of people get commons-fileupload.jar as part of struts or another package and never bother to even read any documentation about it. Your recommendation about even higher security achievable is certainly a good one, but as long http://jakarta.apache.org/commons/fileupload/customizing.html is rather empty, certainly only VERY FEW people are doing it. So, an exposure during processing time of a few (milli)seconds as opposed to months of residing on a disk and possibly even being found during disposal by totally unrelated third parties IS a difference. Agreed, quite some disclaimers would have to go with it, but I think for the little cost it incurs, it is a first step in the right direction worthwhile to take. (at least offer it as a configurable option)
        Hide
        Ralf Hauser added a comment -
        Show
        Ralf Hauser added a comment - see also http://wipe.sourceforge.net/
        Hide
        Ralf Hauser added a comment -

        As our diploma student Marcel won the first Mozilla SECURITY BUG BOUNTY
        (http://www.mozilla.org/press/mozilla-2004-09-14-01.html) I ask myself "why only
        being reactive"? Therefore to be proactive, I offer USD 100.- for whoever
        provides a decent "secure delete" here. Another USD 100.- if it is so good, that
        it ends up as the default in the next release of this package!
        As we'll happily use this once it is available in our service on http://p4u.ch,
        we will match each of these amounts with another 100 USD usage credit for the
        author on the service.

        Show
        Ralf Hauser added a comment - As our diploma student Marcel won the first Mozilla SECURITY BUG BOUNTY ( http://www.mozilla.org/press/mozilla-2004-09-14-01.html ) I ask myself "why only being reactive"? Therefore to be proactive, I offer USD 100.- for whoever provides a decent "secure delete" here. Another USD 100.- if it is so good, that it ends up as the default in the next release of this package! As we'll happily use this once it is available in our service on http://p4u.ch , we will match each of these amounts with another 100 USD usage credit for the author on the service.
        Hide
        Henri Yandell added a comment -

        My vote here is WONTFIX (despite Ralf's millions ).

        If someone contributed a custom FileItemFactory that linked to wipe, that would be cool and we could at least put it on the website, but no one has in 2.5 years.

        Show
        Henri Yandell added a comment - My vote here is WONTFIX (despite Ralf's millions ). If someone contributed a custom FileItemFactory that linked to wipe, that would be cool and we could at least put it on the website, but no one has in 2.5 years.
        Hide
        Jochen Wiedmann added a comment -

        I second Henri's comment. As he said, there is no reason for not adding yet another FileItemFactory, but that's not necessarily a developers task.

        Show
        Jochen Wiedmann added a comment - I second Henri's comment. As he said, there is no reason for not adding yet another FileItemFactory, but that's not necessarily a developers task.
        Hide
        Ralf Hauser added a comment -

        see also FILEUPLOAD-78

        COM-1710 now is IO-70

        Show
        Ralf Hauser added a comment - see also FILEUPLOAD-78 COM-1710 now is IO-70
        Hide
        Jochen Wiedmann added a comment -

        Even after 3 years, you are still the only one who is asking for such a feature. So I think that the previous reply still applies: You're welcome to provide a different FileItemFactory or a similar patch.

        Show
        Jochen Wiedmann added a comment - Even after 3 years, you are still the only one who is asking for such a feature. So I think that the previous reply still applies: You're welcome to provide a different FileItemFactory or a similar patch.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ralf Hauser
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development