Just wanted to know what could be the security cautions I should know about PHP Hosting?
Thanks
Here are some of the things:
Disable functions like eval, passthru, shell_exec,etc
Remote url injection, disable allow_url_fopen
Disable register_globals
And don't forget:
You are responsible too. Write secure code, read security tutorials out there.
PHP Security Guide
Finally as suggested by Rook, you should run:
PHPSecInfo script to see security settings of your host.
http://phpsec.org/projects/phpsecinfo/
For webhosts and Development Teams
In development environments make sure you have appropriate coding standards. If you feel you are hosting insecure code which you did not write, consider installing a Web Application Firewall. Also consider steps to prevent bruteforce attacks (for example if you are hosting popular CMS tools), an Intrusion Prevention System like Fail2Ban can help you do this. A lot of these issues are covered in this talk Practical Web Security – Junade Ali, the video of the talk is here.
For PHP you can also consider using Suhosin which adds a number of security features to the PHP core. Be careful installing it first and test your sites afterwards to ensure it doesn't break anything.
If you speak as developer (and not as hoster), then don't rely on the server -- write secure code and you won't be harmed by any php configuration directive ever.
Clients often have access to Perl, PHP and shell accounts which makes it easy for a client to DoS or Denial of Service all the other clients with a badly written program.
External DoS on the whole hosting service, which means that if an IP is experiencing a DoS attack, you also suffer the same problem with the others.
Most often than not, clients of shared hosting solutions also share an IP address with other clients. This arrangement often works out fine but it is important to know that whatever happens to your neighbours sharing the same IP with you will also get to you. If your neighbour using the same IP will be placed on a spam blacklist, everybody else using the IP will also share the same fate.
It is very vulnerable to malware attacks.
Other harmful data can be uploaded in the other sites easily, putting your site at risk. These can be introduced to the server through vulnerabilities of a legitimate clients’ website and can be used steal data.
DDoS attacks launched by software loaded into the server allow hackers to control an entire hosting server and then attack other server, either from the same network or from other networks.
Related
I'm hosting a couple of sites for my friends, which they can edit using SFTP. But I recently stumbled upon something quite alarming.
Using: <? echo $realIP = file_get_contents("http://ipecho.net/plain"); ?>
They are able to get the real IP of the server. I'm using CloudFlare to "mask" the IP from the outside, so that's quite safe. I know that I can use a VPN for this, but that a quite expensive option. Is there any way to avoid, them using this certain methodes to gain the real server IP?
I would just generally secure the server in a way that is similar to typical shared hosting accounts.
While this is on the edge of what I know, I am by no means an expert on server security I do know a few things I have ran into over the years.
disable using stream file wrappers for remote files. This is controlled by the allow_url_fopen setting in PHP, and disables opening remote files using fopen, file_get_contents and their like.
disable some of the more dangerous PHP functions these include but are not limited to shell_exec, exec, eval, popen. These likewise can be disabled in the PHP ini file by adding them to the disabled_functions list.
remove shell access for the users. They will still be able to authenticate for sFTP, for file transfers. But they will not be able to login via SSH through something like putty you can modify the users like this usermod -s /sbin/nologin myuser for more details see this post on Unix.StackExchange
setup a test account with the same access your clients (people you provide hosting for) have and test what works and what doesn't. This will give you a bit of an idea what they can and cant do, and it gives you a place to test some configuration changes before applying them globally.
I am sure there are many more things you can do, and I can't really go into a whole article on server security. As I said I am by no means an authority on the subject. So the last thing I would say is do as much research as you can and see what others are doing for shared hosting servers as this is basically what you have.
I did find this Post on 14 best practices on server security.
http://www.hostingadvice.com/how-to/web-hosting-security-best-practices/
This just gives a high level overview of some of the concerns and doesn't really get to overly technical.
This is a pretty big topic, with many pitfalls, but I hope my limited knowledge at least gets you started down the road of securing your server. And remember, it's your server you get to say what the policies are on it.
That said it is very important to communicate with your users about any policy changes. They have pretty much had free reign up to this point. But if you explain to them that it's in their interest because it not only protects the server but also protects their data, it may go over a bit easier. They do have a right to know, and you do have an obligation to tell them. This way they can make any necessary changes to their code. But again, it is your server ultimately and it's your responsibility to make it as secure as you can.
Good Luck!
Currently I'm working with PHP programming, and I find that I can load a web page just only by using PHP CL, so I don't understand exactly why we have to install additional server like Apache or Nginx.
I don't know why your question was voted down. I see it as a question for focusing on a slightly broader but highly related question: Why should we be extremely careful to only allow specific software onto public-facing infrastructure? And, even more generally, what sort of software is okay to place onto public-facing infrastructure? And its corollary, what does good server software look like?
First off, there is no such thing as secure software. This means you should always hold a very skeptical view of anything that opens a single port on a computer to enable network connections (in either direction). However, there is a very small set of software that has had enough eyeballs on it to guarantee a certain minimum level of assurance that things will probably not go horribly wrong. Apache is the most battle-tested server out there and Nginx comes in at a close second as far as modern web servers are concerned. The built-in PHP HTTP server is not a good choice for a public-facing system let alone testing production software as it lacks the qualities of good network server design and may have undiscovered security vulnerabilities in it. For those and other reasons, the developers include a warning against using the built-in PHP server. It was added because users kept asking for it but that doesn't mean it should be used.
It is also a good idea to not trust network servers written by someone who doesn't know what they are doing. I frequently see ill-conceived network servers written in Node or Go, typically WebSocket-based solutions or just used to work around some issue with another piece of software, that implicitly opens security holes in the infrastructure even if the author didn't intend to do so. Just because someone can do something doesn't mean that they should and, when it comes to writing network servers, they shouldn't. Frequently those servers are proxied behind Apache or Nginx, which affords some defense against standard attacks. However, once an attacker gets past the defenses of Apache or Nginx, it's up to the software to provide its own defenses, which, sadly, is almost always significantly lacking. As a result, any time I see a proxied service running on a host, I brace myself for the inevitable security disaster that awaits - Ruby, Node, and Go developers being the biggest offenders. The moment a developer decides to write a network server is the moment they've probably chosen the wrong strategy unless they have a very specific reason to do so AND must be aware of and prepared to defend against a wide range of attack scenarios. A developer needs to be well-versed in a wide variety of disciplines before taking on the extremely difficult task of writing a network server, scalable or otherwise. It is my experience that few developers out there are actually capable of that task without introducing major security holes into their own or their users' infrastructure. While the PHP core developers generally know what they are doing elsewhere, I have personally found several critical bugs in their core networking logic, which shows that they are collectively lacking in that department. Therefore their built-in web server should be used sparingly, if at all.
Beyond security, Apache and Nginx are designed to handle "load" more so than the built-in PHP server. What load means is the answer to the question of, "How many requests per second can be serviced?" The answer is actually extremely complicated. Depending on code complexity, what is being hosted, what hardware is in use, and what is running at any point in time, a single host can handle anywhere from 20 to 20,000 requests per second and that number can vary greatly from moment to moment. Apache comes with a tool called Apache Bench (ab) that can be used to benchmark performance of a web server. However, benchmarks should always be taken with a grain of salt and viewed from the perspective of "Can we get this application to go any faster?" rather than "My application is faster than yours."
As far as developing software in PHP goes (since SO is a programming question site), I recommend trying to mirror your production environment as best as possible. If Apache will be running remotely, then running Apache locally provides the best simulation of the real thing so that there aren't a bunch of last-minute surprises. PHP code running under the Apache module may have significantly different behavior than PHP code running under the built-in PHP server (e.g. $_SERVER differences)!
If you are like me and don't like setting up Apache and PHP and don't need Apache running all the time, I maintain a set of scripts for setting up portable versions of Apache, PHP, and Maria DB (roughly equivalent to MySQL) for Windows over here:
https://github.com/cubiclesoft/portable-apache-maria-db-php-for-windows/
If your software application is actually intended to be run using the built-in PHP server (e.g. a localhost only server), then I highly recommend introducing a buffer layer such as the CubicleSoft WebServer class:
https://github.com/cubiclesoft/ultimate-web-scraper/
By using a PHP userland class like that one, you can gain certain assurances that the built-in PHP server cannot provide while still being a pure PHP solution (i.e. no extra dependencies): Fewer, if any, buffer overflow opportunities, the server is interpreted through the Zend Engine resulting in fewer rogue code execution opportunities, and has more features than the built-in server including complete customization of the server request/response cycle itself. PHP itself can start such a server during an OS boot by utilizing a tool similar to Service Manager:
https://github.com/cubiclesoft/service-manager/
Of course, that all means that a user has to trust your application's code that opened a port to run on their computer. For example, what happens if a website starts port scanning localhost ports via the user's web browser? And, if they do find the port that your software is running on, can that website start deleting files or run code that installs malware? It's the unusual exploits that will really trip you up. A "zero open ports" with "disconnected network cable/disabled WiFi" strategy is the only known way to truly secure a device. Every open port and established connection carries risk.
Good network-enabled software will have been battle-tested and hardened against a wide range of attacks. Writing such software is a responsibility that takes a lot of time to get right and it will generally show if it is done wrong. PHP's built-in server feels sloppy and lacks basic configuration options. I can't recommend its use for any reasonable purpose.
If you refer to the PHP documentation:
Warning
This web server was designed to aid application development. It may
also be useful for testing purposes or for application demonstrations
that are run in controlled environments. It is not intended to be a
full-featured web server. It should not be used on a public network.
http://php.net/manual/en/features.commandline.webserver.php
So yes, as it states, this is a good tool for testing purposes. You can quickly start a server and test your scripts in your browser. But that does not mean it provides all of the features you get with a production level server like apache or Nginx :)
You can use the built in server in your local development environment. But you should you use a more secure, feature rich web server in your production environment which requires much more features in terms of security, handling large number of requests etc.
Can xampp configured with virtual hosts cause a security threat if it is run on a computer used as a normal computer and not a server? Example: I want to run xampp with virtual hosts on my mom's mac laptop. She uses it for emails, web-surfing, etc. Would this put her at risk for being hacked or personal information at risk? Thank you in advance!
you can deny all ip address and just add exception to no one can access the webserver
i think phpmyadmin used in xampp and appserv have vulnerability and can get shell access to
.htaccess file for deny ip :
order deny,allow
deny from all
allow from 111.222.333.444
111.222.333.444 => ip allowed
if you deny port 80 for other ip , it should be safe :D
by the way should take care about services you run on your operation system
there is no such thing as "a server", not in the way you obviously understand the term. "A server" is nothing but a simple computer that "serves" something, thus the term. Every computer is a server and every computer is a client. Whyever, somehow the term "a server" has become common for systems used mainly to server things, like for example "web server". That does not change the fact that the expression does not really make sense from a technical point of view.
certainly running a server software on any system adds a security risk to that system, since it exposes the system, makes it communicative. That is the sense of using a server software, so there is way around that. You can only try to limit the security thread, you cannot prevent it.
In the end it absolutely depends on what you server with xampp used as a "server software". There are many many web applications out there that pose high security risks on the system they run on. Bad programmed applications, unknown issues, all the bandwidth.
In addition the configuration of the server software is crucial when it comes to security. You can easily leave wide open gaps and accidentially make private data accessible to the public or risk that the system is taken over and turned into a bot or a zombie. So you should limit access to the system as far as possible. Block everything you do not really need. And, preferably, do not connect such a system to the internet, if you only need it internally.
So the answer clearly is YES, THERE IS A SECURITY RISK.
You should only run server software if you know what you do and if you know how to handle it.
And you certainly should never do that on someone elses system!
The answer here is: it depends.
If you are using this for internal support, then no. This will not cause a serious security risk on her computer. At least no more than anything else you do. Yes, by adding the server software, you can have other computers connect to it, but it depends on what you are doing with this server. If you are using it for internal development, you'll be fine. If you are THAT worried about it, make sure you aren't connected to the internet. However, if you are trying to host a web site with high traffic, then you may want to consider another option, like an actual server, rather than a local host.
To be honest, there is a security risk in EVERYTHING you do. Connecting to the internet in a coffee shop. Visiting web sites. Opening emails. They are ALL risks. So you just have to understand what you are doing. By adding virtual hosts, you can connect one computer to another; however, if this is for testing, and doing things internally, the chances of someone getting that IP address is extremely low.
My site is under DDos Attacks (UDP Flooding)!
I have no access to linux shell and only cpanel is available for me! :(
Is it possible to prevent this attacks by php scripting?
Is there a way to configure cpanel to reduce or redirect attacks? How?
According to web hosting help desk: Attack is between 6 to 10 Gbit/s !!!
Is the following code useful?
<?PHP
if (!isset($_SESSION)) { session_start(); }
// anti flood protection
IF($_SESSION['last_session_request'] > time() - 2){
// users will be redirected to this page if it makes requests faster than 2 seconds
header("Location: /flood.html");
exit; }
$_SESSION['last_session_request'] = time();
?>
Hardware firewall is too expensive.
First, if you are under attack, protect by sessions is not effective.
Second, if you implements an anti-dos method under php, you are adding process, and the DOS attack is ever effective.
The web server listen on TCP protocol, a udp attack is to the server, no your site, prevent the attack is on side of the server, a.k.a, your hosting provider.
Sorry my english
You will want to enable mod_qos in easy apache's exhaustive options
You will also want to install ConfigServer Firewall. That software can help detect dos attacks and block them. Link Below.
http://configserver.com/cp/csf.html
Banning IP will not prevent SYN-floods and will not be effective for botnet DDoS either. There is also no real code solution for DDoS and even Firewall will only go so far.
having said that I got 2 suggestion:
1.) If you are looking for Firewall protection, and Hardware Firewall is out of your price range, please know that there are Cloud Based WAF solution that are available for under 60$/month. I work for Incapsula and our company actually provide all Bussines plan client with a fully configured and customizable PCI DDS compliant Cloud WAF as one of the security features. Currently we are the only ones to offer a PCI DDS compliant version, but - if PCI compliance is not an issue - there are also other solutions you can consider.
2.) For 100% DDoS protection you must have a large enough "pipe" as even the above mentioned WAF will not provide a full-proof filtering solution. For this you will need to use a reverse proxy that will supply you with the "muscle" and flexibility needed to handle DDoS attacks (by balancing and deflation).
I also want to point you to this discussion in security.stackexchange.com that talks about IP blockage as a means for DDoS Mitigation:
https://security.stackexchange.com/questions/17632/iptables-ddos-protection-working-with-per-client-ip-address-counter-and-udp/17634#17634
You should make some sort of black hole page that will automatically ban the IP addresses that are making the requests on your server.
Also, you can manually ban IP addresses (single or ranges) using cPanel's IP Deny Manager
Edit:
Also, considering you do not have shell access to your server, I would contact your host immediately for further help.
You can't protect a server from DDoS attacks using PHP. The code you provided simply stops people from requesting that page more than once every two seconds.
If you don't have access to shell, then somebody else does. That somebody needs to fix the problem, not you.
PHP-Scripting will help you absolutely nothing against UDP-Flooding. Only thing that helps a bit is to DROP any unplanned UDP-traffic using e.g. iptables. Still, 10GBit/s is way too much.
Let's say I have a website where
PHP 5.3 is installed
every output is htmlspecialchars()ed.
PDO and prepared statements are the only way to interact with the database
error_reporting() is off
every request is passed to index.php (front controller) and no direct file access is allowed except for index.php via .htaccess
every input is properly escaped (why should I? i use Prepared statements, how could an user input mess up with my code?)
there's no use of evil()
Is it considered safe? What other things could be fixed to improve security? How could you attack it? Hack it? PHP/Server side is possible to improve security?
Check this page : PHP Security Guide. Most attacks are documented. If after implementing these security checks, you're still hacked, there are high chances that the problem doesn't come from your PHP application.
By the way, as #Jacco stated, there is some wrong stuff on the article I linked to.
Use prepared statements instead of mysql_real_escape_string(), but you already did that.
About salting, follow this answer instead : https://stackoverflow.com/a/401684/851498
Finally, checking ['type'] (for file upload) is unsafe since a malicious user can change this value. Instead, see the suggested solution of this link : http://www.acunetix.com/websitesecurity/upload-forms-threat.htm
I remember when I started web developing, I read allot about sanitizing data, creating numerous mysql users with a subset of permissions for specific queries, etc.
It gets you in the mindset of treating security with code, not with the operating system.
What use is all of this if you connect to your console with telnet, or use ftp with authentication?
I guess I should cut to the point. I think modern open source technologies such as php mysql etc have build up allot of security features, which gave me a false sense of security.
The damage you can do through these technologies is negligible compared to hacking into console with a brute force attack. If I were you I would worry much more about geting a proper firewal and only allowing port 80 or the bare minimum of ports you need. If you enable console access I would only allow your desktop IP... etc.
and make sure if you ever send a password, that it is encrypted through ssl
There is no absolute security guarantee, you can add the following to the answers above:
If you allow file uploads, make sure you do mime checking;
Make sure the public cannot upload an unlimited amount of files to
overload and eventually kill your server;
If you own the server make sure there are no other weak gates to your site, you can spend millions making your site bulletproof to any type of attack, but if someone gains access to it through another website hosted on the same server, you're out of luck;
Use a vulnerability scanner like acunetix, skipfish;
If you own the server make sure you stay up to date with the versions of the software running on your server (PHP/Apache/MySQL). Subscribe to get updates from the vendors;
If the budget allows it, you could offer a bounty to someone to find a security hole in a DEV release of your code;
Use a product like the following: https://www.cloudflare.com/features-security
security is a major concern for any product and it can not be achieved by some finger count policies but they are important so everywhere in the code think the negative possibilities and work against them to prevent them.
other thing you have to do
store sensitive data in encrypted formate in db
clean XSS every user input data
It is important to note that "safe" is a context-based term. It highly depends on your needs, and there are companies out there (I'm looking at you Google) who will not even consider installing PHP at all.
If you are working at a big company, I would recommend hiring the services of professionals.I heard from a friend that this company does sec checkups for all the big companies, which seems likely since they are the people that distribute Kali Linux.
https://www.offensive-security.com/offensive-security-solutions/penetration-testing-services/
There can be multiple other issues as well, such as session problems, sensitive information enumeration, authorization and authentication issues, and lot more. Issues like business logic bypass can not be resolved by traditional secure coding guidelines. However, looking at PHP Security Cheat Sheet and OWASP PHP Security Project would be a great help to understand the big picture of security issues.
You can learn more about exploiting PHP security issues and related attack techniques by solving the PHP security challenges by RIPSTech (https://www.ripstech.com/php-security-calendar-2017/) or by reading their writeups of real-world vulnerabilities found in popular PHP apps (https://www.ripstech.com/security-vulnerability-database/)