I have been doing a lot of research on this and I can't seem to find a definitive answer. Obviously these days security is a big issue, hacks are going on all over the place of major companies that invest millions into security and they're still getting hacked.
I work on Laravel a lot and use shared hosting with Hostgator or some similar company of high report. Laravel comes with a built in function for encrypting database info and decrypting to the user when requested.
However, I have a question on how secure this ACTUALLY is. If someone gets into my cPanel, my app key which is used for encryption is right there in front of them. Granted, my cPanel password is the one that's auto-generated by Hostgator and it's complete jibberish with semicolons and alphanumeric strings all over, so it's not easy to guess.
But I'm trying to learn a little bit more about security. If my app key in my env file is locked securely behind my cPanel login, is Laravels built in "encrypt()" method "enough" to call an app "secure"? Is there other measures within Laravel or my host provider that could make it more secure than just tight passwords? Is there some sort of practice of referencing the app key through an external source that's not located in the cPanel area? So even if my cPanel got hacked, my app key wouldn't be in those files and get exposed?
I'm not a security expert, but there are a few points I can share from my experience in working at highly-secured companies.
First, Laravel itself is fine. You can generally trust open source software since it's transparent and security bugs get discovered and addressed early. So you don't need to improve Laravel, just use it as is, preferably an LTS version.
Then, CPanel is a liability. You should minimize weak points on your system, i.e. those that are externally accessible. Get a VPS or a private server and access it via an SSH, don't use tools like CPanel and PhpMyAdmin on it. The less software you have that talks to the outer world, the less vulnerable you are to bugs in that software.
In my current company the production server can only be accessed via SSH from a single IP address, the address of the dev server. So I log in to dev server first, and then log in from there to the prod. It denies all connections from all other IPs.
If you are limited to using CPanel or something similar, consider protecting the login page with HTTP Basic Auth, some hosting providers allow that.
You also want to keep your system and software up to date. Not too new either as that may have bugs that haven't been caught yet. Our devops prefer to have it a couple of minor versions behind, so that the community has time to test it out and get hacked for you.
That's all I know as a web-dev, sure enough there are special tools and ddos protection services but that's beyond a dev's concern imo. If you just follow these steps, you should be safe. Hope that helped a bit, cheers :)
Related
guys I just want to ask a couple of questions about security problems, if this is not the place to ask these questions then please close the question.
I want to make a web application with Laravel where u can watch movies (it would be used only by me and a few friends of mine). I'm going to turn my old pc into a server and use it for the app. My questions are: (if the answers are too long then please provide a link where I could read about this).
What can a hacker do if he hacks into my server (don't care about data that much since there will be no personal information inside of it) and how to prevent it? Keep in mind I don't want to pay for any firewalls if it's not absolutely necessary.
if the hackers gain access into my server and the server is connected to my router. Can he gain access to the router and then other devices connected to the router. How can I prevent this from happening?
In Laravel Forge there's an option called Website Isolation, which some people also seem to mention as user isolation as well. I am not quite sure what it does and possible benefit for such functionality. It would be great if someone can explain this!
It also means you can assign different users to different sites on your server. You can give them SSH and SFTP access to a specific site without allowing them access to other sites on the same server. It also can prevent malicious code in one site from affecting another site on the same server if these sites have different users.
See https://blog.laravel.com/forge-user-isolation
I found out that one of the biggest advantages for using Website / User Isolation is that Laravel Forge will be then able to offer unique and independent nginx environment compared to other sites exist in the same server. Thus, in situations where it requires restarting an nginx or overloading, other sites in the server should work perfectly fine.
I am using shared hosting.
My site was showing "ERR_CONNECTION_REFUSED".
So i went to see visitors to my (SSL) site.
I found that instead of regular names in the "User Agent" list,
cpanel visitors list is showing
user agent Expanse indexes the network perimeters of our customers. If you have any questions or concerns, please reach out to: scaninfo#example.com"
I want to know whether this is harmful and if yes,
How to avoid such unknown user agents?
Is there something i should do with ".htaccess" file?
Once again, i am using shared hosting (so, i have limited accessibility).
The ERR_CONNECTION_REFUSED you saw when accessing your website had nothing to do with the visitor you saw in cpanel. You might have had a different issue with your server configuration/shared hosting provider.
That "visitor" was an internet crawler, most likely from Palo Alto Networks, who owns Expanse. Long story short, it shouldn't cause any harm. They say that their crawlers are used to index/categorize URLs around the internet and/or to spot malicious content.
I advise you to ignore it, since there's not much you can do - I assume they have some ranges of IPs for their crawlers so you wouldn't be able to blacklist all of them anyway.
I many articles where writers show how to deploy a Laravel app/website on shared hosting they discourage doing that. In some other quora questions where the answers state that it is possible but has some security risks. So what security risks does this practice implies.
The honest answer depends on the type of project and-or customer (agency vs interprise).
If you are working for a smaller project and there is no on-going development (extra possible invoicing) to it I will recommend using a shared hosting.
But if your budget is pretty high and that application needs to grow, handles sensitive user data, automated deployments, unit testing together with Docker and Vagrant for local development. I would recommend using AWS or digital ocean.
The biggest problem using AWS is that it pushes the responsibility to you in keeping the operating system and PHP-version up-to-date.
With interprise customers, I would recommend using services like:
Use a security scan (https://detectify.com/)
Use a Firewall (https://www.cloudflare.com/en-gb/)
Basically it all depends on the type of customer you are dealing with.
But for a really small / tiny projects, just use a shared hosting and basically never forget to use CSRF, ReCaptcha, throttling requests, ... Be smart about it.
Forgive me if this would have been better placed somewhere else on the stackexchange network but I have seen a few Laravel questions being asked here so thought it would be OK.
Anyways...
I have a Laravel app which I want to get online and found some hosting here: https://www.server4you.net/virtual-server
The pricing is really good and there is root / SSH access. As I dont know if my web app will be a financial success I dont wanna go all out on a dedicated server but also don't mind migrating it at a later date (I know this will be a pain!)
I have seen a few people online recommend against using a VPS / shared server for a laravel app...my question is why?
If the servers can perform as advertised then this should be good?
I have never bought a vps or uploaded my own Laravel project to a server before so I feel like I should ask these questions now before I realise I have shot myself in the foot somehow way down the line...
Cheers!