I am looking for best practices, modules, etc. to securely do file system manipulation via PHP application. The CMS-like application will not use a database, but instead the markdown files are placed in folders and are processed at display time. Therefore, there will be a lot of moving files around, renaming files, writing to files, etc.
I am looking to either find some libraries (e.g., equivalent to an ORM) that will help to manage such actions, input sanitization, moving files. etc. rather than start from scratch. If nothing like this is available, I would like a listing of best practices, etc.
So far I have only found guidance from PHP.net.
More information: The plan is to build a web based end-user interface which sits ontop of Stacey. I would have a test environment with the end user interface, and when changes are ready they are then synced to the production environment. This is a non-DB based system. Stacey is convenient to manage and work with from a developer standpoint, but user's don't want to work directly with markdown and move files, etc.
Also: Please limit the answer to PHP issues; server things like chrooting or locking down the server would be dependent upon the user's individual environment and needs. From a development standpoint, I want to focus on securing my distributed code.
I don't know of any specific libraries that do this -- the filesystem support in PHP is extensive so I'm not sure why they'd be necessary. You might be better off starting with an existing CMS and modifying it to do what you want -- however I understand that might not be possible. It also sounds like the sort of thing that should be using a database, but I guess you already know that.
I can't claim to know exact best practice, this is more general advice.
First, your web server -- and therefore your PHP scritps -- will be running as a certain user. This depends on your configuration and particular server as well as the underlying OS. Ideally you want to make sure this user only has access to the filesystem area that your using as storage. Deny all access to everywhere else apart from read-access to where it really needs (your scripts, etc) and read-write to the storage area. The exact way to do this depends on your system.
That's your last line of defense, do not rely on it, it's there as a safety net.
It's not clear exactly what will cause files to be renamed, moved, altered but it's a safe bet that it's from user input. Therefore you need to make sure you sanitize all user input, if their page name becomes a file name you want do not want to let some enter ../../index.php as a page name and nuke your main site.
Always assume the worst case: a user who knows the internals of your system intimately and is aiming to do most damage. Do not rely on 'security by obscurity' or 'nobody will ever do that'.
What I would do (and have done before) is two fold. First wrap all the filesystem functions up into a class that provides the same functions as methods. The job of this class is to check that anything happening is allowed, that means it's probably going to have to read the paths and filenames and work out the location of the changes.
Secondly, sanitize all user input that could be malicious when it first arrives. You might want to look at using escapeshellarg or URL encoding, or something else depending on what your input is.
You also mention files are processed at run-time, if users are allowed to write scripts (or worse PHP that gets executed) then you have a lot more issues and may have a fundamental problem. But that's not clear from your question.
Hope that helps.
Related
I'm new to WordPress, and I'm building some backend logic to it.
I want the admin to have as smooth experience with it as possible.
I want for him to be able to run the website with "a click of a button".
I'm used to Java and nodeJS environments, where I have life cycle,
where I can specify logic to happen when the server starts, but I'm having trouble to understand how it's done in WordPress(or PHP for that matter).
I want the website to check the database and see if it has needed tables for it's functioning, and if not, to create them and fill them with relevant data, as well as to check if the database is up-to-date (in case of a long crash),
and update if necessary.
Right now I'm thinking about running a Cron script to check it, every few minutes but it's heavy on resources. A better solution might be to run it on the first interaction with a user, but it seems not ideal, as it will slow him down.
Is there a life cycle in WordPress?
should I be worried about it crashing during important operation and then starting on it's own?
Can I specify logic for it to run on it's boot/restart?
I am not completely sure what you have in mind when you say "fill them with relevant data", but I would either recommend, leveraging WordPress' own logic or complete your task using other tools.
Just like any php script, it is stateless and it has an index.php as starting point. Then files are loaded in order and the contents of your request and the environment will depend where you end up.
This is just how php works and the key difference with JS is that JS executed on your computer, and php is a set of server side scripts that are compiled and will produce some sort of output that is sent back to your browser, just like when you call a REST api.
You might want to take a look at the following things:
wp-load.php: the file that will look for your constants defined in wp-config.php, when this file is not yet present it will redirect you to the "famous" wordpress site setup (after loading a bunch of stuff related to database connections and request data). You could follow the logic, but I would advise agains that. This due to the fact that the WordPress core is very old and this gives you an example of how php applications from the early 2000s used to look like and will most likely cause headaches.
Existing tools
Not only on server level, but also things like wp-cli or maybe a composer based solution like roots/bedrock or even roots/wordpress.
To answer your question about lifecycles directly
Yes, WordPress offers an old-timey hook system, but this is just during the request lifecycle for an active install, so this wouldn't be exactly what you seem to be looking for.
Finally, it is good to have some understanding of the internal workings of WordPress, but the whole reason that WordPress is easy to run and compatible with many setups, is just because they "strive for forever backwards compatibility" (which is also why they don't use semantic versioning). Which in turn means that the core is very outdated and unreadable, so I wouldn't bother trying to figure it out yourself.
And even more so I wouldn't want you to think that this is a fair representation of the PHP-world, since the initial release of WordPress, the language has completely evolved and most of the key components to it being a nice developer experience were still a long way ahead.
In short, I'd look for existing solutions which are built for your specific server setup and if that is not possible for some reason, try to find some sort of CLI tool in php, or other languages.
We are working on making a wordpress type system from scratch with a templating system and am wondering about security. We hope to have a SaaS model where the user will be on the same server as a few other users, but we hope to also give them the tools to modify their own Views files, which means PHP access. We are using Laravel as the framework. As a long time Dreamhost user, I know you can section the same machine off into multiple environments, but not really sure what they were using to do so.
How can I prevent the execution of commands like eval(), system commands, and limit the users access to fopen (I assume that is mostly through the linux user permissions). I would like to give them direct file access to the Views folder and to develop their own solutions instead of forcing them to go through me, but without jeopardizing too much. If there are mysql considerations beyond separate users, feel free to chime in there as well.
There are several layers that you need to protect.
Some of the hosters incorrectly rely on PHP "protections" like open_basedir, safe_mode (older PHPs), disable_functions etc.
Even PHP does NOT consider them being security features - http://php.net/security-note.php
These can be disabled with any exploit for PHP and then the whole system is doomed, do not do that.
How it should be done
the bottom
Separate OS-level/system user for each hosted site
correct permissions (one can't be able to view/edit page of the other one) - also make sure sub-directories have correct permission as they're going to be similar
separate session files (LOT of webhostings put session files of each PHP-hosted site into the same directory, that's bad bad bad!
Apache finally got it's own module for this - Apache MPM-ITK.
Long story short: picture this as you'd give the user a shell on the machine (under his own uid) - he can't be able to do anything to the other hosted sites.
different uid/gid
system permissions
framworks like SELinux, AppArmor and similar
grsecurity if you want to be hardcore.. but the system will be harder to maintain.
going up?
You can get more hard-core. The best I've seen is a shared-library for apache (or whatever you use) - that is used when apache is started using LD_PRELOAD and it implements all the potentially malicious system calls like system(), execve() and basically any other call that you find bad.
I haven't seen a good implementation of this out there yet (other than custom ones somewhere) - correct me if I'm wrong.
Make sure to implement a white-list for this as eg. mail() in PHP executes sendmail by default and that won't work anymore.
conslusion
Add classic disable_functions, open_basedir, etc. into global php.ini, add session.save_path to every vhost - put sessions into user directories. Make sure users don't share anything.
Implement underlaying OS-level separation correctly.
Get hardcore with grsec and LD_PRELOAD lib hooking system calls.
Separation, separation, separation .. soon enough systems like Docker will provide LXC-based containers to separate users on kernel level but it's not quite production ready yet (imho).
Where i begin to work, they are using a Remote Desktop Conection, to transfer files and manage the server, but that seems to me really insecure and a good way to cause errors and take down the apache/php/mysql stack.
I was proposing FTP to transfer files more easyly (and secure compared to the other way) but started reading about php deployment. It seems pretty easy on Linux, but on windows i havent found out wich is the best way to do it..
So far i think git on the server, and comit to it from the developer is my best shot, but what about database deployment?
Phing/jenkins/capistrano seem overly complex.. but will try if you guys think is good
The approach I am using is database migration scripts. They look like this
db-update-001.sql
db-update-002.sql
I have a script which sequentially executes them and creates *.ok file for each if it's successful. *.sql files contain "alter" statements and are stored in Git. The .ok files are not stored, so if you distribute changes, you need to imprint only those without .ok files.
I use this file: https://github.com/atk4/atk4/blob/master/tools/update.sh
but since you are in MS environment, you might need to do something different.
While MSRDP is not the most secure protocol around, its a very long way aead of FTP.
FTP is intrinsically insecure - it sends passwords as clear text. It's also a PITA to manage across a stateful firewall even where you can ensure consistent PASV behaviour.
However you do need a method for transfering files which can be scripted / automated.
I'd go back and have a long hard look at the available deployment tools - I can't comment on how well the other products compare with phing, only having used the latter - however mostly I've used stuff developed in house.
Since you really should be using a version control system - I'd recommend considering using it as your file delivery mechanism too.
I'm thinking of protecting my script to the mass majority of users (non-web dev savvy) and I came across an online service to encode php script. I'm not sure about it though.
Is it safe to encrypt php script? What if the encoded code has something fishy in it?
If you intend to distribute the PHP file then I would suggest that you do not do this. It's only going to irritate those that want to tinker with it.
If for some reason you don't want them tinkering with it, then don't distribute the PHP file.
If you need to distribute the file AND you don't want them tinkering with it, then I would highly suggest you not do this in PHP and instead write the functionality using C as an extension to PHP.
You'll notice that at no point do I suggest you actually go ahead and "encode" the php file. That's not going to buy you anything.
If you are looking to obfuscate your server-side PHP, the best bet would be to use a commercial product such as Zend Guard (http://www.zend.com/en/products/guard/). Any home-brew encryption is not secure in the slightest - your code can be easily reverse-engineered with fairly trivial effort. The page you link to does not have any credibility, it is just someone's side project. They have no accountability or stake in protecting your information.
Even these commercial products (Zend Guard, ionCube, phpShield, SourceGuardian) can be decrypted if someone really, really wanted to. No tool or technique in any language can make absolutely secure obfuscation, there is no "unhackable" system. Everything boils down to effort over time.
If it isn't important enough to bother doing it right, then you're probably wasting your time on the issue. Further, if it is absolutely vital that some information or code remain private, you should simply not put it out into the public purview.
[edited for clarity]
Ultimately, you need to trust the encrypting party. If you don't trust them (apparently you don't), then don't give them access to your server (through executing their decryption code/your obfuscated code, possibly with who-knows-what else inside). Simple as that, albeit possibly inconvenient.
php is usually running on the server where the users have no access to the code(neither source nor any other representation) anyways. No reason to obfuscate it there.
Obfuscating php is only useful in the rare cases where you give the php code to clients. For example if you want clients to be able to run their own server but not give them full access to the code.
So, it looks like all it does is obfuscate the code so it's not human-readable. The only way this would really be useful is to prevent lazy people who have access to the code from reading it. However, it uses simple functions to encode/decode, so it would be trivially easy for someone to decode it if they have access.
Which brings me to my point... PHP security works by not allowing anyone to have access to the source file. If someone who shouldn't have access gets it, then this "encoding" thing isn't going to do you any good.
The OP mentioned an interest in protecting database connection details, and it should be kept in mind that no matter what protection system is used for the code itself, the PHP engine and component libraries being opensource sets some absolute limits on what can be achieved. If MySQL connection details, for example, are hidden in a script then these details could be trivially revealed without going near the PHP scripts themselves simply by running the scripts with a PHP build that had slight modifications to the MySQL library or the associated PHP module wrapper. Even hiding the details in a C module as suggested by Chris L. would afford no extra protection in this case. Good protection can certainly be given to source code with compiled code systems such as ionCube and Zend, but wherever data hits routines in the PHP core then it can be exposed.
Obviously for any online service where you may be sending sensitive details, you should use due diligence and make best efforts to ensure that it has a good pedigree. Apart from anything else, not having a working https URL for the site the OP questioned should immediately warn that it's a no-no, and not just for the lack of connection encryption but showing that they are not offering a service that they consider to be serious.
I want to make a news portal(php) with minimum mysql force.
:create a cron, fetch data from mysql and write to a php file . (I dont know is it right way)
But Can I use xml instead of php file? Write mysql data to xml.
Is this a secure way? What is the best way? XML or php file?
alt text http://img541.imageshack.us/img541/4784/87392425.gif
Thanks in advance
Let me start of by saying that MySQL is very fast and very secure. I recommend building the pages with MySQL upon request, most web applications do this because its a very good approach. To save resources you can cache the output using a Squid Reverse Proxy, and it is very common to see this on high traffic sites. PHP's APC will also reduce resource consumption without sacrificing secuirty. Smarty's Caching system is also a good approach with minimal security impact.
There are secuirty concerns regardless of what method you choose, but some approaches more hazardous than others. For instance creating .php files with user input is probably the most dangerous thing you can attempt to do with a php web app.
$page='$title="'.$_GET['user_title'].'"';
file_put_contents("/var/www/page.php",$page);
An attack against this code would look like this:
http://localhost/page_creater.php?user_title='; eval($_GET[backdoor]); /*
Creating XML files with user input is also dangerous because it opens the door for Advanced LFI Attacks. However, the counter argument is that as long as your application is free from Local File Include vulnerabilities, then you shouldn't have to worry. But this is not a "Defense in-depth" design, because you should plan on failure.
Its possible to implement something like Squid's reverse proxy in php using ob_start(), however your still creating files with attacker controlled data, and that is hazardous. Also don't include() .html files that's incredibly stupid (See advanced LFI attacks...), a better approach is this: print(file_get_contents($file)). I do like using .html files over using .xml files because html doesn't have to be processed before outputting it to the user. Using xml files as a data storage is wasteful of resources when compared to MySQL.
(Disclaimer: Vulnerabilities have been found in Smarty and squid, and php, and linux, and mysql and apache and.... everything else, even StackOverflow ;)