I am developing a website which provides the option that clients can upload their PHP scripts to a specific directory on my server. I want to make sure that my system is secure, and thus I do not want people to be able to use those PHP scripts to edit or view files outside of the directory they are uploaded to. In other words, if there is a file at public_html/directory1/foo.php, it should only be able to edit and view files in public_html/directory1, and should not be able to edit or view files anywhere else on the system. Is there any way of doing this?
This is super dangerous. Technically there are ways to do this if you know your way around linux/windows user and group configuration, Apache configuration, and PHP configuration. You'll need to run Apache under a user with extremely specific permissions and configure PHP to forbid certain types of commands (most notably the exec/system commands, but there are a lot of other ones that are likely to get you in trouble).
I'd strongly suggest you try to figure out a way to avoid giving your users the right to upload files to a folder where they'll be evaluated by the server as PHP. There's just too many things that can go wrong, and too many settings that can be overlooked.
If you do decide to go this route, do a lot of reading on secure PHP configuration and Apache Privilege Separation.
Since PHP is a server side script, I belive you'll find it hard to properly secure your system. Having said that, you can limit those files by running the apache server by a user which have no access to other directories, check SElinux for more info. please note that it's really hard to do so, you might forget even one file which can be used later to hack the system.
A better way might be running these server on top of a VM, so that even if someone hijacks the VM, you could always shut it down and restore it's data.
Related
I have found that I have a similar attack to the one mentioned here
giant regex hack
The file keeps getting recreated and I cannot see from where its coming. How can I fix this? Anyone with a similar experience? I am running joomla 1.5.25
How can I trace the script that includes this file? How do I secure the site?
Its always recommended that you keep the permission of your .htaccess file as readable only.
chmod 0555 .htaccess
But regarding the hack being created again and again, there could be just numerous reasons. Like the host not properly configured, such that, on a shared hosting, a script running for a different domain can access scripts for your own domain.
Also check, what kind of files do you allow to upload, whether it's Admin or Frontend. Make sure, its not just any file upload is allowed. Executable files like PHP should not be allowed to be uploaded.
Yikes, that's not a good situation. I've seen it happen a few times and more often than not the solution was to recreate the website from a clean Joomla install, copy over the data and reinstall components.
However first check that the permissions are ok (no 666, 777, etc) and definitely check the VEL to see if any of your extensions have know vulnerabilities http://docs.joomla.org/Vulnerable_Extensions_List
You could also check on the Inj3ctor database http://www.1337day.com/ .
Most hacks like these happen via out of date extensions, open permissions, or as linuxeasy mentioned a poorly configured host.
Would highly recommend installing jhackguard or eyesite on the website. Eyesite will monitor your files and notify you when changes occur -http://extensions.lesarbresdesign.info/extensions/eyesite
I'm currently developing a PHP framework. Other developers may create modules for the framework. Source code of these modules should reside in the framework directory.
Since the project is open-source, modules know location of the config file which has database password in it. How to protect passwords from malicious modules? Please check that modules may just require_once the config file and do harmful things!
Currently I'm storing Database passwords in a directory named config, and protecting it by a .htaccess file:
<Directory config>
order allow,deny
deny from all
<Directory>
But that is not sufficient to prevent scripts steal the password, is it?
I've read the thread How to secure database passwords in PHP? but it did not help me finding the answer.
In PHP, you can't. It's not a sandboxed language; any code you run gets all the permissions of the user it's running under. It can read and write files, execute commands, make network connections, and so on, You must absolutely trust any code you're bringing in to your project to behave well.
If you need security boundaries, you would have to implement them yourself through privilege separation. Have each module run in its own process, as a user with very low privileges. Then you need some sort of inter-process communication. That could be using OS-level pipes, or by having separate .php files run as different users running as web services accessed by the user-facing scripts. Either way, it doesn't fit neatly into the usual way PHP applications work.
Or use another language such as Java, which can offer restricted code with stronger guarantees about what it is allowed to do (see SecurityManager et al).
Unfortunately, PHP is not a very secure language or runtime. However, the best way to secure this sort of information is to provide a configuration setting that has your username/password in it, outside of your document root. In addition, the modules should just use your API to get a database connection, not create one of their own based on this file. The config setting should not be global. You should design something like this in a very OOP style and provide the necessary level of encapsulation to block unwarranted access.
I've got an idea that may work for you, but it all really depends on what abilities your framework scripts have. For my idea to be plausible security wise you need to essentially create a sandbox for your framework files.
One idea:
What you could do (but probably more resource intensive) is read each module like you would a text file.
Then you need to identify everywhere that reads a file within their script. You've got things like fopen for file_get_contents to consider. One thing I'd probably do is tell the users they may only read and write files using file_get_contents and file_put_contents, then use a tool to strip out any other file write/read functions from their script (like fopen).
Then write your own function to replace file_get_contents and file_put_contents, make their script use your function rather than PHP's file_get_contents and file_put_contents. In your file_get_contents function you're essentially going to be checking permissions; are they accessing your config file, yes or no, then return a string saying "access denied" if they are or you use the real file_get_contents to read and return the file if not.
As for your file_put_contents, you just need to make sure they're not writing files to your server (they shouldn't be allowed, imagine what they could do!), alternatively, you could probably use a CHMOD to stop that happening.
Once you've essentially rewritten the module in memory, to be secure, you then use the "exec" function to execute it.
This would take a considerable amount of work - but it's the only pure PHP way I can think of.
I am not sure if it is possible, however you could maybe make a system which checks the files in the module for any php code which tries to include the config file, and then warn the user about it before installing.
However it really shouldn't be your responsibility in the end.
A very good question with no good answer that I know of, however...
Have you seen runkit? It allows for sandboxing in PHP.
The official version apparently isn't well maintained any more, however there is a version on GitHub that is quite popular: zenovich/runkit on GitHub
Although the best solution is perhaps a community repository where every submission is checked for security issues before being given the OK to use.
Good Luck with your project
Well, I see no problem here.
If it's a module, it can do harmful things by definition, with or without database access. It can delete files, read cookies, etc etc.
So, you have to either trust to these modules (may be after reviewing them) or refuse to use modules at all.
Don't include your actual config file in your open source project.
The way I do it is a create just the template config file config.ini.dist
When a user downloads your project they have to rename it to config.ini and enter their own configuration information.
This way every user will have their own database connection info like username and password. Also when you update your project and users download your newest version, their own config files will not be overwritten by the one from your program.
This a a very common way to store configuration in open source projects - you distribute a template config file and tell users that they have to rename it and enter their own configuration details.
I don't think there is a way to prevent a module to capture sensible data from the actual framework configuration and send it to some stranger out there. On the other end, I don't think that should be your responsability to protect the user from that to happen.
After all, it's the user that will decide to install any module, right? In theory it should be him that would have to verify the module intents.
Drupal, for example, does nothing in this direction.
There is a worst problem, anyway: what'd prevent a nasty module to wipe out your entire database, once it is installed?
And, by the way, what could the malicious stranger do with your database password? At the very least you anyway need to secure the connection of the database, so that only trusted hosts can connect to the database server (IP/host based check, for example).
im trying to implement on my site a system who let the user download a file that have to be change before the download.
I have a master file (a .exe program), that inside have a variable who has to be change for every different user.
The most simple solution is to change a variable inside a xml file every time the user want his personalized exe and then make the exe file to read the external file. BUT i dont want the user to download more than one file.
Is this possible? using php can i change a parametter inside a compiled program? Thanks for any help and suggestions!
If you really really know what you're doing and you know exactly the bits that need to be flipped inside the file, then yes, it's possible to modify the .exe file with PHP. Otherwise you have to make changes to the source or other files the .exe is built with and compile the program on the server before sending it to the user.
In theory it's certainly possible (PHP is turing complete), but as stated in other answers it will be hardly worth the hassle (considering the fact that you have to ask whether it is possible shows you'd have to investigate at last for days into the standard exe-format).
I'd recommend one of the following:
1) Zip the program with the configuration file; either use a separate launcher (e.g. Java [a JAR is a ZIP file]) or add a configuration file that is read by the program itself. There is a number of PHP libraries for generating ZIP files.
2) compile the program with the changed source on the server itself; however this can also become quite complicated depending on your server configuration and the programming environment you use. If you have never administered a virtual server I would not even slightly recommend that as an option.
3) If you can assume that the user got somewhat stable Internet access you might also consider to let hir download a standard executable, where additional configuration will be downloaded later on by the program itself (e.g. by transmitting the username to the server). However this creates dependencies you might want to avoid (your user probably can't use it on machines without Internet access and you should assert that your server is up most of the time).
While it's probably possible, I doubt it's worth the hassle. Unless you're trying to fight piracy or something. Why don't you just serve the user a custom .zip file with the .exe and a config .xml?
[edit after OP commented]
I presume what you're trying to edit is the facebook ID/username? Well, try to compile the base file with some unique string like "THISNEEDSTOBEREPLACED", then use some binary safe function to replace it. Though remember things can and will get tricky if the string lengths don't match.
Ok this might seems a bad idea or an obvious one. But let's imagine a CMS like PHPBB. And let's imagine you'd build one. I'd create just 1 file called PHPBB.install.php and running it it will create all folders and files needed with PHP. I mean, the user run it just once and every file and folder of the app is created via the PHP file.
Why to do this?
Well mostly because it's cleaner and you are pretty much sure it creates everything as you wish (obliviously checking everything about the server first). Also, having all the files backed-up inside a file you would be able to restore it very easily by deleting everything and reinstalling it running again PHPBB.install.php. Backing-up files like this will allow you to also prevent errors: How? When an error occurred in a file, this file is restored as it was and automatically re-run.
It would be too heavy!
The installation would happen only once and you'd be sure the user will not forget to place the files correctly. The error-preventing will worth the cause and it would also happen only once.
Now the questions:
Does this technique exists? If so, What's its name?
Why would you discourage it?
As others have said, an installer.
It requires the web server to have permission to write to the filesystem, and ends up having the files owned by the user the web server runs as. Even when one has the ability to change filesystem permissions, it's usually a longer process than just extracting an archive and having the initial setup verify permissions.
Does this technique exists? If so, What's its name?
I'd advise to read about __halt_compiler(). It allows you to mix PHP code with non-php data which is not parsed, so you may have PHP code ("installer") and binary data (e.g., compressed contents of all the files) in single PHP file.
1 - Yes, there is a single install file in PHPBB. You run through an online wizard defining your settings and then it installs automatically.
http://www.phpbb.com/support/documents.php?mode=install&version=3&sid=908f5766fc04868ccb985c1b1e6dee4b#quickinstall
2 - The only reason to discourage it would be if you want the user to understand exactly how the system works. Automatically installing it means the user has no need to understand the nitty gritty of it all - of course, many see this as a good thing.
I am always reading that you should always store your database credentials outside of your document root because normally you would have them set to db.inc or something similar.
I can understand this and naturally it makes perfect sense.
What I don't understand is why you are making the file into one that you either need to set apache to hide or you need to put it into a secure location in the first place.
What is the issue with making it, say db.php - Then apache knows to execute the script first and return the output (which would presumably be blank in most cases).
Maybe I am being dumb and missing an inherent security flaw but is there any issues with just storing your details in a .php file? I mean Wordpress and other major open source PHP applications manage to get away with it, but is this because they can't make their script talk to folders outside of www or because it is just as secure as any other method?
Maybe I am being dumb and missing an inherent security flaw but is there any issues with just storing your details in a .php file?
A tiny slip up in the configuration of Apache, and the file starts being served raw instead of being processed by the PHP engine.
I mean Wordpress and other major open source PHP applications manage to get away with it, but is this because they can't make their script talk to folders outside of www or because it is just as secure as any other method?
They accept increased risk for increased convenience.
Storing files containing (database) credentials outside the document root is always a good idea.
Say, you upgrade Apache, but forget updating the configuration with PHP. Any file in the document root can possibly be downloaded without getting parsed.
Wordpress, Joomla, phpBB and others are made to be portable. That is, reside in one folder.