Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Security on shared server

by derekstucki (Sexton)
on Mar 03, 2014 at 23:22 UTC ( [id://1076814]=perlquestion: print w/replies, xml ) Need Help??

derekstucki has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing a web page that accepts a .csv which contains sensitive PII (personally identifiable information). The site it's going to be on is hosted on a shared server. I currently have the script writing the uploaded file to disk, then reading that file, getting the info I need, then deleting the file. The file should be protected by the OS file permissions while it exists, but I realized that once deleted, it could theoretically be read by someone else on the system. What is the best practice/your suggestion for making this more secure? Keeping the upload in memory ( and dealing with all the security needed for that )? "Shredding" ( overwriting with random patterns or all 0's ) the file after processing before deleting? Something else that I haven't thought of?
EDIT: The shared server in question is on a reputable, PCI-compliant hosting service. I'm not just throwing stuff that should be secure on my neighbor's cousin's "web server".

Replies are listed 'Best First'.
Re: Security on shared server
by einhverfr (Friar) on Mar 04, 2014 at 03:26 UTC

    A number of things to think about.

    • If the server is compromised, your security is toast. If the material is particularly sensitive, you should at least go with a vps, if not a dedicated server.
    • Effects of deleting the file depend on the underlying filesystem. If you can't control that, you can't control what it means to delete the file.
    • How big is the file? Is it something you can just post in chunks to a web server via https and process in memory?
    • Where else do you need to protect the data?
    • If you must store on disk, can you encrypt the file on disk and decrypt during reading? Maybe you can post the key with the upload making it unreadable effectively after the session is done (since the key never hits disk)?

    There is no such thing as perfect security but you need to think through the tradeoffs carefully, and you need to look carefully at the possibility of better security than a purely shared server if it is truly sensitive.

Re: Security on shared server
by Anonymous Monk on Mar 04, 2014 at 00:41 UTC
    ... getting the info I need...

    Is this info you need also sensitive? If so, have you thought about how you're going to secure that once you've parsed it? If not, why does the sensitive information need to be uploaded in the first place, if it's just going to be discarded?

    The file should be protected by the OS file permissions while it exists...

    Are you sure, have you checked? Many web servers make their files accessible to everyone.

    Security is such a vast topic that it's hard to give any good answer without knowing a whole bunch of factors, just a few of which are: what web server and OS you're running on, how sensitive the information is and what steps are supposed to be taken with it, what attacks you are attempting to protect against, and so on.

    To start with, based on what you've written so far, it might be better to just keep the file in memory - as long as you're sure the web server doesn't use temporary files for uploads?

    This should be obvious, but I hope you're using HTTPS?

    If this information is so sensitive that you're worried about the "deleted files may theoretically be recovered" issue, then you really shouldn't be working on a system which (I'm assuming) you don't fully control in the first place.

    From your posting history: parsing XML with a regex, attempting to roll your own date/time calculations, passing form variables into system() - these things are fine for quick scripts (except maybe the system() thing) but not considered good practice for production systems, especially robust ones that are also supposed to handle sensitive data. It's great you're working with Perl and I mean this constructively: I hope you've invested some time into reading a good book or two on modern Perl and the Web before working on security-critical things.

Re: Security on shared server
by jellisii2 (Hermit) on Mar 04, 2014 at 12:42 UTC

    There's a fundamental that I haven't seen mentioned: Who owns the box? Root on the box will have access to your file no matter what you do, and if they aren't a trusted entity, I would check all other avenues for before you even start considering how to secure the data itself. Most places know that there's money that needs to be spent when dealing with any sort of PII/HIPPA/FERPA data. It's the nature of it.

    That said, (along with all the other valid points brought up by fellow monks above) have you considered using truecrypt? You could conceivably put your data in a container, mount the container with a key that you supply or only have access to, then unmount and shred the file if it doesn't need to lurk. If you go this route, I'd see about automating the rotation of keys so each time you have to update the data, you're using a different key each time.

Re: Security on shared server
by moritz (Cardinal) on Mar 05, 2014 at 07:02 UTC
    I'm writing a web page that accepts a .csv which contains sensitive PII (personally identifiable information). The site it's going to be on is hosted on a shared server.

    Don't do that. Seriously. It can only go wrong in the long term, and likely earlier.

    Get a hosting provider that is certified to the standards you need to comply to.

      This hosting service is PCI compliant/certified, which is the level of security we need, and probably this entire conversation is just an exercise in paranoia, but while I'm doing something, I might as well do it as well as possible.

        There's a wipe utility available on most linuxy operating systems (though not always installed by default), but the problem is that journaled file systems don't actually write changes to disk immediately, but rather to a separate journal on disk (which improves reliability in case of crashes). That makes wiping files unreliable, so you might just go ahead and simply delete them.

Re: Security on shared server
by ruzam (Curate) on Mar 04, 2014 at 23:31 UTC

    He who owns the box owns your data.

    It really is as simple as that. Nothing you can do will prevent a curious system admin from simply editing your script to save a copy of everything. Encrypted or not.

    Accept the fact that you are wasting your time looking for creative ways to hide your data on a hosted service. If the security really is that critical, your only option is to run your own server to be sure that no one else has physical access to the box.

Re: Security on shared server
by derekstucki (Sexton) on Mar 04, 2014 at 21:48 UTC
    To answer a few questions, this is on a professional hosting service, which is PCI compliant, and therefore has reasonably good isolation between clients, but one can never be too careful, thus this post.
    Post-processing information is stored securely in a database, so outside the scope of this post. HTTPS, as was stated, is obviously in place and strictly enforced.
    The OS in question is Linux, I've checked file permission security, and it's in place. Root obviously could get to it, but unless the hosting service is compromised, root can be trusted.
    I'm expecting file sizes to be < 1 MB.
    As for my level of experience, I have a BS in CS, almost have my CCNA, and have never had a security audit come back with a problem. I know enough when to ask about things I'm not sure about.
    Encryption on disk is an option, but...
    Thus far, it seems the consensus seems to be for keeping it in memory if the file is small enough. This is feasible, and the direction I'll head at this point, but any additional feedback would be greatly appreciated.

      Keeping it in memory sounds like a good way to go. As stated above, you should probably check that your web server doesn't use temporary files for file uploads.

      It also avoids another issue: what happens if your program for whatever reason fails before it deletes the file (you'd need a cron job regularly clearing out your temp dir, etc.).

      While a certain level of paranoia is useful when working with senstive data, to keep myself from getting too paranoid about things I try to remember what the stated security requirements are, and to stay realistic about what any additional countermeasures I implement actually protect against.

      Just as one example, when using disk encryption, people sometimes seem to forget that as long as those encrypted drives are mounted (which in some cases is all the time), anyone who compromises the running system has access to their contents anyway. So unless you're protecting against the disks being stolen, or people forgetting to wipe them at decomissioning, disk encryption won't help your network security.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1076814]
Approved by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2024-03-19 09:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found