Is there a way to dynamically find a user's cgi-bin path using PHP and write a file to it?
For instance, I want to write a PHP application that also uses a Perl script for additional functionality (will not break without it), and on first run I want to get the path for cgi-bin or whatever the user's directory is named, and write the script into the directory so that it can be invoked by the application, with minimal installation required by the user (i.e. upload application to a directory, then run index.php).
Is this possible? Or am I dreaming far beyond what I can actually do?
The simplest solution I see to this would be to use a regex to check for a directory named /cgi/ starting at the user's root directory, however, this doesn't seem like an entirely reliable method
__FILE__ gives you under both Perl and PHP the name of the currently executed file.
There is no sane way.
A server can be configured to execute CGI programs in zero, one or many different locations, none of which have to have "cgi" in the name.
You could try parsing the server configuration to identify which (if any) locations are set up that way, but you would have to write a separate parser for each server, and each one would be very complex. Even if you limit things to Apache, then you would have to deal with filtering based on virtual hosts, <file>, <directory>, <location>, ScriptAlias, .htaccess, etc.
Related
I am replacing an existing very old site written in another lang with a newly-coded php site and I need to double-check a couple of things with respect to security. Website will be running on Windows 2008 R2 using IIS 7.5 and running php 5.3.8.
I am storing db login creds in a file outside of web root. But in my php code I have to include those files and I am using an absolute path. Will php and/or IIS strip out the file path. (I imagine the answer is yes since competing technologies would do likewise, but need to be sure on this and couldn't find the answer.)
On a related point, what is the best place to keep .js files? Is it better security-wise to keep them outside of web root?
Sorry for the basic questions, but am new to php (long time programmer in other langs).
well, php is different from ASP, so my suggestion is to make a subdomain for js/css, you even can name it CDN... but, it still better than from the root.
I ran a bunch of tests where I looked at the source of what is returned by php and the webserver. If you use the php command "require c:\abc\file.php" neither piece of information is returned with the html.
However, the path to a .js file IS displayed. This is because it sits inside the html, not php, so that path is NOT stripped out by php or the webserver.
So from this I think I can safely say:
1. The path to the creds will not be displayed in the html source returned to the browser or curl call or whatever.
2. js and css paths are shown publicly so it is worth considering whether these need to be secured (e.g., separate subdomain or similar).
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.
I have created a PHP script that takes a large html file and, using DOMDocument, chops it up into smaller files. To save on script memory and without having to use a DB, I've done this sequentially and saved them as hundreds of html files. My question is, how do I make sure these files cannot be visible to the outside world, but still retain the ability to use them as resources for future processing (piece together various files and display them on a page)?
I'm using Amazon EC2 - Centos 6/Apache.
Thank you!
Put them on a directory which isn't a subdirectory of your web root directory (i.e. the publicly opened directory).
Another possible approach (if you are using Apache), is to use an .htaccess file to Deny from all in a directory.
By far the best approach is to store them outside the document root (perhaps one level below).
Otherwise, perhaps at a future point, your settings, .htaccess file httpd.conf or other elements may change and reveal the directory contents.
Storing them outside the docroot means they will never become visible.
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 have a series of web sites all hosted on the same server with different domains. I want to host some common PHP scrips and then be able to call these from the other domains.
Im am a bit fresh with my php so pls excuse code attempts - I have tried iterations of the following which may try and help you understand what I am aiming for!
from within php tags ...
include('http://www.mydomain/common_include.php?show_section=$section');
$show_section = $_GET['show_section'];
include('http://www.mydomain/common_include.php');//Then $show_section would be available to the included file/cod
Finally I have tried pulling in the include which contains a function then trying to run that include from the parent script.
I would much prefer to keep this PHP
orientated rather than getting
involved with the server (file
systems etc (but I can change
permissions etc)
I can but would prefer not to just upload the same library to each of the domains separately
I understand PHP is run on the server hence maybe problematic to include scripts across onto another server.
Thanks in advance.
#
EDIT
OK OK - I get that its bad practice so will not do it....THANKS VERY MUCH FOR THE QUICK ANSWERS.
However is there any other recommendations of how to esentially show this basic php app on all of the sites with out haveing to add the files to the root of each site? Just to prevent massive script duplication...(thinking out loud call the scripts in from a db or anyother soloutions)
Again thanks for your assistance
That would be a huge security risk if you could just include remote PHP files to your own projects. The PHP gets parsed before the server sends it to you so cross-domain includes would only contain the output the script generates. The only way to include PHP files so that they can be executed is via local filesystem.
If you look at PHP.net's documentation about include, you can find this:
If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), you can specify the file to be included using a URL (via HTTP or other supported wrapper - see List of Supported Protocols/Wrappers for a list of protocols) instead of a local pathname. If the target server interprets the target file as PHP code, variables may be passed to the included file using a URL request string as used with HTTP GET. This is not strictly speaking the same thing as including the file and having it inherit the parent file's variable scope; the script is actually being run on the remote server and the result is then being included into the local script.
Which pretty much explains the whole thing.
The root of the original question seemed to be the poster's concern about using a PHP script or plugin on multiple sites and then having an onerous task each time it needs to be updated. While trying to include PHP files across sites is a bad idea, it is a better plan to structure your script to be as self contained as possible. Keep the entire plugin contained in one directory.... and ensure your function calls to utilize it are as well formed as possible - clean, well named functions, uniform naming conventions and a well thought out plan for what parameters each function needs. Avoid using global variables.
Ideally you should then have quite an easy time each time you need to update the plugin/script in all locations. You can even set up an automated process that will upload the new directory containing the plugin to each site replacing the old one. And the function calls within your code should rarely if ever change.
If your script is big enough you might implement an automatic update process like the more recent versions of Wordpress use. Click a button and it updates itself. In the past, updating a dozen sites running Wordpress (as an example) was a massive pain.
That is very bad practice.
Actually you're including not PHP but just HTML code.
Include files, not urls. It is possible for the same server.
Just use absolute path to these files.
Apart from the fact that it's a bad practice you should first check if include allows URLs if you really want to do that.
If however all the sites that need to use the script, you could put the script somewhere in a directory accessible by the user that executes php and add that dir to the php.ini include_path property (can also be done at runtime)
(Or you could create a php extension and load it as extension)
If you have root rights on that server, you could just use absolute path from filesystem root, but most hostings won't let you do this.