Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am new at using and programming web applications, so I wanted to ask a question. Is it safe to execute os commands like copy and mv and delete from a web app that is running on an apache, or does it bring up security issues?More specific I am using django, and I want a view of mine when it is executed to be able to run os commands like copy move etc to folders that reside outside the var/www folder. I know how to use os module but I haven't found from my web search if it is safe to do it.

share|improve this question
1  
Same question on SO: stackoverflow.com/q/24406242/53114 –  Gumbo Jun 25 at 10:38
    
Yes they suggested I post it here. If it is not allright please delete or close :) –  Apostolos Jun 25 at 10:41
    
It would be better one would be migrated to the other site. But only admins can do that. –  Gumbo Jun 25 at 10:43
    
Does the user input have any influence over what is copied/moved/etc? Are they uploading anything? –  Andrew Hoffman Jun 25 at 10:43
1  
If its a trusted environment and user input doesn't influence it in any way that can be exploited, then I see no probs with it. –  Andrew Hoffman Jun 25 at 10:48

3 Answers 3

up vote 10 down vote accepted

If user input has no influence on the commands or their arguments, there should be no immediate threat.

But it is always a risk, you might be missing something or there might be (i.e., there are for sure) unknown vulnerabilities in the software you're using (e.g., Django).

What I would do to mitigate those cases would be to:

  1. Verify your permissions. Assure your using the minimum privileges needed for those operations you need (maybe Apache's user has too high privileges for what you need, create another user with less privileges);
  2. Whitelist only the commands you're going to need (block everything else);
  3. Look into setting up a controlled filesystem for those operations (e.g., some sort of 'chroot');
  4. Harden your server (look into Grsecurity and RBAC);
  5. Obviously keep everything patched and updated.
share|improve this answer
    
Mounting your controlled FS separately also helps contain resource exhaustion problems (e.g. when inodes are scarce) that can lead to larger denials of service. –  Mike Samuel Jun 25 at 13:35

When you build commands which include user-supplied strings, there is always a risk of command injection.

Example code which is supposed to copy a file to a name provided by the user:

$command = "cp template.png " + $filename + ".png";

When the filename is supplied by the user, they could pass this:

$filename = "foo.png ; rm *";

resulting in the OS receiving

cp template.png foo.png ; rm *.png

which are actually two commands, the second one being malicious (remove all png-files from the directory).

share|improve this answer

Yes, it can! This is extremely insecure and considered one of the top poor practices in the security industry. There are many things that can go wrong:

  • You may just let people type whatever commands they want, and it won't take long before they make your server download and execute a malicious binary of their own making.
  • You may suffer a category of attacks as described by @Philipp called "OS Command Injections". It occurs when you execute commands on user-provided data, and users provide you data such that they append sequences of extra commands to it. The best approach to fixing this issue is to write a function that will receive the command and data separate and always sanitise/escape the data.
  • Even if you limit yourself to a few commands like cp and mv, users may provide filenames pointing outside your working directory, such as "/usr/bin/apache", which in @Philipp's example would result in your Apache binary being removed and your server no longer working next time you reboot it.

Now, I don't know what you're trying to do but if you insist on proceeding, keep the following in mind:

  • Authenticate your users, and verify that they are authorised to use your view
  • Only allow commands within a white-list, and separate commands and data as said above
  • Sanitise data systematically by escaping special characters and verifying that it belongs to a legal space (e.g. filenames are within a legal space, not containing any folder name for instance); see the Clark-Wilson model
  • Sandbox your Web server and if possible, get a specific server/worker to run this special view of yours (see SELinux modules for Apache, especially look at how RHEL 7 uses SELinux and systemd to sandbox services); Go even further if the same server runs anything actually sensitive and contain the server running your web view in a LXC or Docker container (not entirely secure yet but better than nothing)
  • Get your code and your server audited by an external penetration testing team
share|improve this answer
    
very analytical response...thank you a lot! –  Apostolos Jun 26 at 7:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.