I am currently building a simple CMS, and I would like to isolate it as much as possible. The application itself will have php login function, however I was thinking to add one more layer of security utilising Apache built-in security.
How secure is to isolate a PHP directory on a server using integrated apache password check? The general logics is that Apache security should be pretty tough to crack.
Thanks!
I understand your concerns about your code in progress. It is better to work on localhost till you reach a point when you are certain in your code, but what you can do:
Password protect your folder (can be sniffed).
Limit your folder access by IP (can be faked)
Make this php script run as a separate user with access rights only for this folder, so even if you have security breach it won`t impact your server or other scripts running on it.
Make sure you are using database user that have permissions only for your test database.
Create a fake domain, put a record in your hosts file and make your script accessible only from this domain (for example: app.staging.lo)
All this combined will be secure enough to keeps you away from troubles.
Related
Just as the question says... I've read up a few articles, others says just don't do it, but yet fail to mention a safe way. I know it hazardous to give it sudo access or root, but I was thinking about running a script that has root access through root.
One post was talking about a binary wrapper, but I did not fully understand it when I attempted it and when I tried to do a search to understand I didn't find anything that explain it well.
So, what would be a good-safe way? I don't even need to have a detailed explanation. You can just point me to a good source to start reading.
Thanks.
Specs:
Ubuntu Server 14.04
EDIT:
Commands I am talking about is mkdir, rmdir with an absolute path. Create user, remove user (which is why I need root) and edit some Apache files for me.
They fail to provide a safe way because, IMHO, there isn't one. Or, to put it another way, are you confident that your code that protects the create user and add user functions is cleverer than the hackers code that tries to gain access to your system via the back door you've built?
I can't think of a good reason for a web site to create a new system-level user. Usually web applications run using system users that are created for them by an administrator. The users inside your web site only have meaning for that web site so creating a new web site user gains that user no system privileges at all. That said, it's your call as to whether you need to do it or not.
In those cases where system operations are necessary a common approach is to build a background process that carries out those actions independently of the web site. The web site and that background process communicate via anything that works and is secure - sockets, a shared database, a text file, TCP-IP, etc. That separation allows you to control what actions can be requested and build in the necessary checks and balances. Of course it's not a small job, but you're not the first person to want to do this so I'd look for an existing tool that supports this administration.
I have not been able to find solid information on preferred (best practices) and/or secure methods to allow php to access config or other types of files on a linux server not contained in the public web directory or owned by the apache user so I'm hoping to find some answers here.
I am a fairly competent PHP programmer but am increasingly tasked with writing web applications (most of which are not publicly accessible via the web however) that require updating, changing or adding to config files or files generated by some service or application on the server.
For instance, I need to create a web interface that will view, add or remove entries from a /etc/mail/spamassassin/white-list.cf file owned by root.
Another scenario is that I need php to parse mime messages in /var/vmail that are owned by user vmail.
These are just a couple examples, there will be other files in locations owned by other processes/users. How can I write PHP applications that securely access and manipulate these files without opening security risks?
If I were needing to implement something like this, I would probably look at using something like sudo to fine-tune permissions. I'm not a Linux CLI expert, so I'm sure there are issues that I haven't taken into account when typing this out.
I would probably determine what tasks need to be done, and would write a separate script for each task that needs to be completed. Using sudo, I'd assign the necessary level of permissions for that script only.
Obviously, as the number of tasks increase, so would the complexity and the amount of work involved. I'm not sure how this would affect you at the moment.
A strange thing occurred today. I have made a CI based site, and a hacker managed to:
Overwrite my index.php file by making a file upload to root;
Inject code direct into my index.php replacing everything with a dummy html formatted page;
I don't know which of the above actual occurred.
The site is quite simple (no input forms, no db ecc.), I started developing it with CodeIgniter since client didn't know what he wanted, so I ended up using the framework just for templating and compressing.
I have strong doubts whether a security hole was offered to the hacker on the PHP side. I am incline to believe the issue is from my hosting service bad server configuration (I had a bad chat with them, they say they will look into it)
I find it very curious that only the index.php was (apparently) modified (application and system are also in the root since I do not have FTP access above, maybe if I were an hacker I would have deleted any file in root before allowing my fancy index to showy perform)
How did this happen? What do you think is most likely possible?
Unfortunately no one will give you a straight answer without full access to the server, the server and system logs etc. It could be one of many things, if you are on a shared hosting, simply bad configuration of the server will often mean enough (meaning if a person compromises one site, he compromised them all). It could be outdated services on the server, where the attacker used a publicly available exploit. It also might be CI based exploit, private or public...
Chances are, if you are confident that your website couldn't have been hacked, it will most likely be a badly configured shared hosting environment and permissions, allowing the attacker to access system commands and folders that don't belong to the user, which often would've been followed by uploading a php shell via a vulnerable site and from there it would be as simple as browsing folders of a web server.
Second likely I would say is that it could have been outdated exploitable service running on the shared host.
If there is any "signature" in the html you were talking about, you might want to try to google it and see what returns. Also you might want to try to execute some system commands via PHP (something you shouldn't be able to access like ls level below your web root; if you are able, it is likely the attacker access your files that way.
So, I'm writing a php script which will be tied to a cron job that will backup my site's db on a regular basis. The db will get saved to a new sql file daily just incase anything unfortunate should happen to the live version. I am aware of how bad it would be for someone to be able to get a hold of one of these files, exposing both the db structure and user email addresses (passwords are encrypted).
I am not extraordinarily security savvy, and this is one of those things you HAVE to get right the first time around. I'm not to prideful to admit when it's best to ask for help so I figured I'd inquire with the trusted Stack Overflow community. (I realize it's likely there is a question similar to this somewhere, but I have been unable to find it).
What steps do I need to take to make sure these files can't be accessed? Note, it is an Apache server. Is it enough to store them in a directory outside of the root which is limited to group read/write (no public read)? Or is it necessary to password protect the directory or even encrypt the actual files? I'd really rather not if I don't have to (encrypt the files), it would just make it more of a pain to use them, but if it's needed...
Also relevant, access to these files is NOT being built into an application interface. I don't need or want to have them accessible by an http request. FTP only. So my question isn't regarding any password protection of a UI.
Thank you all so much for your time!
Storing on the server
If you must, store them outside of the web root and download them with something like rsync over ssh.
Best option (assuming you're running MySQL)
Don't store them on the server, but rather run a cron on your local machine and use ssh and MySQL to do the dump to your local system. That way there is no ominous file someone can have that contains all of your data (unless of course your local network is compromised).
Another option (again another example with MySQL)
You might also look into doing database replication with your local machine by setting up a local MySQL server.
I wrote a PHP web-application using SQLite and sessions stored on filesystem.
This is functionally fine and attractively low maintenance. But, now it needs to run on a shared host.
All web-applications on the shared host run as the same user, so my users' session data is vulnerable, as is the database, code, etc.
Many recommend storing sessions in DBMS such as MySQL in this situation. So at first I thought I will just do that, and move the SQLite data into MySQL too. But then I realized the MySQL credentials need to be readable by the web application user, so I'm back to square one.
I think the best solution is to use PHP as a CGI so it runs as different user for each web-application. This sounds great, but my host does not do this it uses mod_php. Are there any drawbacks from an admin's point-of-view for enabling this? (performance, backward compatibility, etc)? If not then I will ask them to enable this.
Otherwise, is there anything I can do to secure my database and session data in this situation?
As long as your code is running as the shared web user, anything stored on the server is going to be vulnerable. Any other user could write a PHP script to examine any readable file on the server, including your data and PHP code.
If your hosting provider will allow it, running as PHP as a CGI under a different user will help, but I expect there will be a significant performance hit, as each request will require a new process to be created. (You could look at FCGI as a better-performing alternative.)
The other approach would be to set a cookie based on something the user provides, and use that to encrypt session data. For instance, when the user logs in, take a hash of their username, password (as just supplied by them) and the current time, encrypt the session data with the hash, set a cookie containing the hash. On the next request, you'll get the cookie back, which you can then use to decrypt the session data. Note however that this will only protect the current session data; your user table, other data, and code will still be vulnerable.
In this situation, you need to decide whether the tradeoff of the low cost of shared hosting is acceptable considering the reduced security it provides. This will depend on your application, and it may be that rather than trying to come up with a complex (and possibly not even very effective) way to add security, you're better off just accepting the risk.
I don't view security as all or nothing. There are steps you can take. Give the web db user only the permissions it needs. Store passwords as hashes. Use openid login so users provide their credentials over SSL.
PHP on cgi can be slower and some hosts may simply not want to support more than one environment.
You may need to stick with your host for some reason, but generally there are so many available that it is a good reminder for people to compare functionality and security as well as cost. I have noticed many companies starting to offer virtual machine hosting -- nearly dedicated server level security in terms of isolating your code from other users -- at what is to me reasonable cost.
A shared host is no way to run a web site if you are conscious about privacy and security of your data from the sites that you share the server with. Anything accessible to your web application is fair game for the others; it'll only be a matter of time before they can access it (assuming they do have incentive to do that to you).
"you can place your DB connection variables in a file below the web root. this will at least protect it from web access. if you're going to use file based sessions as well, you can set the session path in your user's directory and again outside the web root."
I don't have an account so I can't downvote that.. but seriously it is not even relevant to the question.
Duh you store stuff outside the webroot. That goes for any hosting scenario and is not specific to shared hosting. We're not talking about protecting from outsiders here. We're talking about protecting from other applications on the same machine.
To the OP I think PHP as CGI is the most secure solution, as you already suggested yourself. But as someone else said there is a performance hit with this.
Something you might look at is moving your sessions and db to MySQL and using safe_mode and/or open_basedir.
I would solve the problem with a infrasturcture change instead of a code one.
Consider upgrading to a VPS server. Nowdays you can get them very inexpensive. I've seen VPS's starting # 10$/mo.