Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
If this has been inserted by an attacker, there are a few things you can do to improve security. The main ones that come to mind are:
Sanitise file uploads (if your site allows them) - users should never be able to choose filename or save path for files on the server.
Make sure your code directories are not writable by the web server user (apache?).
Thank you for your answering. I'm sure that this is an attack because we wrote this file and when we compared the file that is located on the server with the source file on our PC, there was this difference.
Can you please explain more about you 1st and 3rd solution?
1. The file will be uploaded to a temporary location, and this location will be passed in $_FILES['name_in_form']['tmp_name'] (generally something like "/tmp/phpOqF3Xs"), and the name on the user's system will be passed as $_FILES['name_in_form']['name']. What I was suggesting is that you should be cautious about storing the file on the server using the original name - instead, your script should select the path and filename (and store the original name in a database if it needs to be retained). This would negate any attempts by the user to overwrite a file already on the system (even if permissions allowed this).
3. Some HTTP actions are intended to change data on the server. In particular, the PUT method requests the server to store a document at a particular URL (and DELETE does what it sounds like). By adding a <Limit...> directive in the <Directory...> section(s) of your Apache config, your can lock this down.
Another point is that it's best to get PHP to check the type of any uploaded files (using the mime_content_type() function), to protect against an attacker managing to spoof the type sent to the server.
The question is, what types of files do your users need to be able to upload? The more limited, the better. If a site I was managing did need to allow users to upload executable files, then I'd want to spend some time investigating the risks and measures needed to protect against them (including making sure the upload directory is not directly accessible from the web, that PHP scripts cannot run from there, that files do not have the execute bit set, etc., etc.).