Okay, so the PHP script exists on serverA. ServerA has php safe-mode ON and WebDAV OFF. I can't change either of these factors. I want a script on serverA to get the user's login/password for another server, which we shall call serverB. ServerB has WebDAV ON.
The ultimate goal is that the user will go to the script on ServerA, put in their credentials for ServerB, and then the script will create an iCal file and place it on ServerB, allowing the user to then subscribe to the iCal file using Outlook/GoogleCalendar, etc (which requires the file to be on a WebDAV server).
So, I tried
fopen(servername/filename, r)
and was able to read files on the remote server. But when I tried
fopen(servername/filename, w)
I get an error that the HTTP wrapper doesn't support writing, only reading.
Long story short, is there a way to connect to this server and authenticate, write a file, then close the connection WITHOUT using any of the already-existing WebDAV libraries for PHP and without getting hit with a safe-mode permissions error?
Thanks!
The problem is that the the HTTP protocol wrapper for PHP doesn't do PUT.
You should attempt to write your own, with either fsockopen, or preferably something like curl.
http://ca3.php.net/manual/en/wrappers.http.php
This has nothing to do with safe mode.
The issue here is that Safe-mode is designed to restrict you so you can not execute things outside your "safe" zone.
What you could try (if you can) is to modify the safe_mode_exec_dir in php.ini, then you can start external programs that could do the writing of the file for you (if they reside in this safe-mode directory
About authenticating, I'm not sure, perhaps someone can answer that in more detail.
Related
I'm trying to figure out how (if possible) to do this:
I want to have a server/space/cloud-storage without apache storing a php file, then, another server actually running and parsing that file.
This is because I know Dropbox (Copy, Google Deive, etc) does store any type of file but cannot run php files due to security and due to the lack of Apache.
I therefore thought it may be possible to have a server requesting the Dropbox php file, parse it and return the HTML result.
I thought of this solution and I tried making an include from an external source:
include_once("https://dropbox.com/whatever/file.php");
But is not feasible... Any solution?
Use the API of Dropbox instead of the webview. Then store the value in a variable or temp file and output the result of eval($codeFromDropbox); and delete it if you don't need it anymore.
Dropbox provides you a PHP class (also see the reference) to archive this or you can simply use the global HTTP API Docs to write this small script on your own.
Once you did the authorization as described in the API docs you can simply download any file you have the permissions for.
You can actually include remote files but it is disabled by default:
http://php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen
ini_set('allow_url_fopen', true);
This is OFF (false) by default because it is a VERY HIGH security risk.
It's also a high security risk using eval(). The whole idea is risky.
Why don't you store and the files on the PHP server you want to execute?
Update:
The ini configuration is allow_url_include, not allow_url_fopen, but you should lookup both.
I'm writing an API using php to wrap a website functionality and returning everything in json\xml. I've been using curl and so far it's working great.
The website has a standard file upload Post that accepts file(s) up to 1GB.
So the problem is how to redirect the file upload stream to the correspondent website?
I could download the file and after that upload it, but I'm limited by my server to just 20MG. And it seems a poor solution.
Is it even possible to control the stream and redirect it directly to the website?
I preserverd original at the bottom for posterity, but as it turns out, there is a way to do this
What you need to use is a combination of HTTP put method (which unfortunately isn't available in native browser forms), the PHP php://input wrapper, and a streaming php Socket. This gets around several limitations - PHP disallows php://input for post data, but it does nothing with regards to PUT filedata - clever!
If you're going to attempt this with apache, you're going to need mod_actions installed an activated. You're also going to need to specify a PUT script with the Script directive in your virtualhost/.htaccess.
http://blog.haraldkraft.de/2009/08/invalid-command-script-in-apache-configuration/
This allows put methods only for one url endpoint. This is the file that will open the socket and forward its data elsewhere. In my example case below, this is just index.php
I've prepared a boilerplate example of this using the python requests module as the client sending the put request with an image file. If you run the remote_server.py it will open a service that just listens on a port and awaits the forwarded message from php. put.py sends the actual put request to PHP. You're going to need to set the hosts put.py and index.php to the ones you define in your virtual host depending on your setup.
Running put.py will open the included image file, send it to your php virtual host, which will, in turn, open a socket and stream the received data to the python pseudo-service and print it to stdout in the terminal. Streaming PHP forwarder!
There's nothing stopping you from using any remote service that listens on a TCP port in the same way, in another language entirely. The client could be rewritten the same way, so long as it can send a PUT request.
The complete example is here:
https://github.com/DeaconDesperado/php-streamer
I actually had a lot of fun with this problem. Please let me know how it works and we can patch it together.
Begin original answer
There is no native way in php to pass a file asynchronously as it comes in with the request body without saving its state down to disc in some manner. This means you are hard bound by the memory limit on your server (20MB). The manner in which the $_FILES superglobal is initialized after the request is received depends upon this, as it will attempt to migrate that multipart data to a tmp directory.
Something similar can be acheived with the use of sockets, as this will circumvent the HTTP protocol at least, but if the file is passed in the HTTP request, php is still going to attempt to save it statefully in memory before it does anything at all with it. You'd have the tail end of the process set up with no practical way of getting that far.
There is the Stream library comes close, but still relies on reading the file out of memory on the server side - it's got to already be there.
What you are describing is a little bit outside of the HTTP protocol, especially since the request body is so large. HTTP is a request/response based mechanism, and one depends upon the other... it's very difficult to accomplish a in-place, streaming upload at an intermediary point since this would imply some protocol that uploads while the bits are streamed in.
One might argue this is more a limitation of HTTP than PHP, and since PHP is designed expressedly with the HTTP protocol in mind, you are moving about outside its comfort zone.
Deployments like this are regularly attempted with high success using other scripting languages (Twisted in Python for example, lot of people are getting onboard with NodeJS for its concurrent design patter, there are alternatives in Ruby or Java that I know much less about.)
I have a multi-user PHP web application that can interact with an FTP server via AJAX. The application allows the user to browse an FTP site. Javascript makes an AJAX call which communicates with a server-script that returns a list of files and directories within a given directory.
This works fine. However, each time a directory listing is requested, the server must re-establish a connection with the FTP server, which takes a lot of time.
I need to persist an FTP connection PHP resource across AJAX calls. In other words, the connection must remain open, and I must be able to run ftp_nlist() using that resource, without re-establishing the connection or re-authenticating, with each new AJAX call (until the connection times out, of course).
Can anyone think of a way to do this?
I don't think it's possible using the FTP library in PHP. I see somebody even had a feature request for it in PHP, but it doesnt seem there was any action taken on it.
The only way I can think of is to use a 3rd-party FTP client that keeps the connection open and interface with it through PHP. (instead of a 3rd party ftp client, you could just use the FTP functions built-in to the OS. Windows provides them, as does Linux through the "ftp" program.)
Sorry to add clutter without a clear answer for ya but this might be helpful:
http://www.eecho.info/Echo/php/client-url-library-php-curl/
It appears you are in control of opening and closing the connections however in terms of returning this variable to the client and having it re-used I'm not sure that is possible (also it might just clean itself up out of your control), alternatively you might (depending on the end environment) consider using a Java backend, you could code up a simple server and just add the FTP code on top (mmm... cake). Some examples of what you'd need to do for that are here:
http://fragments.turtlemeat.com/javawebserver.php
http://www.javaworld.com/javaworld/jw-04-2003/jw-0404-ftp.html
This assumes a pretty large amount of control of what's run in the server environment though so really depends on you owning the server basically or having full priveleges to do do what you want (like Amazon EC2 from what they advertise at least). You might be able to pull this off with Tomcat or some other JSP container and use JSPs instead of writing your own server but I don't know that you'd be able to persist the connection their either since it's sort of the same as PHP where the server generally interprets the file "on the fly" so to speak.
You can not create a persistent FTP connection with PHPs normal ftp classes functions. Are all users accesing the same ftp server or are you running a ftp web interface? If multiple users are connected to the same server (with the same rights) you could implement a cached solution.
I ended up making this work using global variables (eg. $my_global). I have a ConnectionPooler singleton class which manages connections stored in a hash.
So, if this question has been asked before, I'm sorry. I'm not exactly sure what to search for.
Introduction:
All the domains I maintain now are hosted on my server, so I have not ran into this problem yet.
I have created a structure, similar to WordPress, for uploading and editing images.
I regularly create changes in the functions and upload them to a single folder. When the user logs in, the contents are automatically downloaded into their folder.
What I am wanting to do:
Now, say I have a user that is not hosted on my server. I cannot use copy(), but is there a safe and secure way to echo the contents of each php file (obviously, I can echo) into another file on the users server?
For example:
Currently I can copy from jasonleodurbin.com to geodun.com (same server), but say I want to copy jasonleodurbin.com/test.php to somedomain.com/test.php.
I had some thoughts like give each user a private key and send that to a file like echo.php. echo.php will grab the contents of every file (that has been modified recently) and echo that to the screen. The requesting server would take that content and copy that into it's respective .php file.
I assume I could send the key through GET, but since I have never dabbled into the security implications of anything (I am a hobbyist), I don't know how secure this is.
Are there any suggestions or directions that someone could send me?
I appreciate the help!
I'm assuming this is sensitive data. If that's the case, then I would suggest encrypting the file using PGP keys. Either way, you need a method to send the file from your server to their server. I can't recall how I did it, but I used to send encrypted data file from our remote server to a server in house. We used PGP keys to encrypt and decrypt once it arrived in house. As for the method we used to send the file across the web, I believe we used SCP (you need shell access on the server).
You could use FTP, but how about setting it up so that they only have access to a particular directory so they can't touch anything else. You'll need a script to grab the file from the FTP location and storing it in the appropriate directory per user?
Just thought of something, store the file in a protected folder. Have the user download the file using curl. I believe you can specify username/password with curl.
Several options:
Upload the newest version of test.php as test.phps (PHP Source file, will be displayed instead of run) in a location know to the client. It is then up to them to download this file and install it on their web server.
pros: not much effort required on your part, no keys or encryption required.
cons: everyone can view the contents of your PHP file if they know where to look, no guarantee that clients will actually get updated versions of the file.
Copy the file to clients web server. Use scp, ftp, or some such method to update test.php on the clients web server whenever you change it.
pros: file will always be updated. Reasonably secure if you use scp
cons: extra step required for you, you will have to remember to do this each time you change test.php. You will need to have access to the clients web server for this to work
Automated copy at a timed interval. Set up a cron script that syncs test.php to the clients web server at a certain time each hour/day/week/whatever
pros: Not much repeated effort required on the part of either party. Reasonably secure if you use scp
cons: could break if something changes and you're not emailing when an error occurs. You will still also need access to the clients machine for this to work.
There's probably a lot more different ways to do this as well, but this is just a few to get you started
Use a version control system, such as subversion. Just check in your code to the repository each time you make some changes you want to push, and run an update from the clients. If you're already using a version control system, create a production-branch where you commit your changes when they're ready to be pushed to clients.
It can be done from the clients in pure php (slightly experimental) with library from here or here, with a PHP extension, or with a wrapper to the native svn client.
This gives you security, as each user can have their own password, which you can retract if you so please. Can also do encryption by running through a ssh tunnel (limits your library choices to the wrapper I think), but really, wouldn't worry too much about encryption, who's going to be looking at the traffic between the servers? Unless you're doing top secret type stuff.
It also gives you automatic change detection, you don't have to roll your own way of keeping track of which files are updated as this is done when you commit your new changes.
It's a proven way of doing code bases up to date, so I don't see why you would implement your own. It also gives you the extra advantage of being able to roll back changes if (when) there's a problem with the code update.
Is there really a way to do this ? Retrieving raw .php file from the server (other than getting into server's FTP account) ? Is this the reason why there are tools/script to encrypt php source code ?
If it's true, then how to protect against it ? (without using php source code encryption)
edit: the server mentioned has php running, eg. apache-php-mysql, your standard hosting server configuration.
If you are talking about someone else's server, then the short answer is no. If third parties could read your PHP source code, that would be quite a security hole, since PHP files tend to contain database passwords, hash keys, proprietary algorithms and other goodies that you don't want falling in the wrong hands.
If you are talking about your own server (ie. that you yourself have access to), then there are simple scripts that you can put on the server, that allow you to specify a path to any file on the server and have it returned as plaintext.
However, you NEVER EVER want to place such a script on a production server, for the reasons mentioned above.
Generally speaking, you can't access remote source code. The PHP module would have to be disabled for this to occur.
But as a thought experiment, how might this happen?
Leaving aside wholesale exploits which get access to the entire filesystem, imagine if there were a security hole in an application which allowed you to insert an line into an .htaccess file. Given that an .htaccess writable by the httpd process is useful for apps like Wordpress, it's not too outlandish a possibility.
If you added this:
php_value engine off
The source files now become downloadable!
It is possible if the server is not well configured that PHP files are not handles as such.
Some examples:
Some servers are configured to show the highlighted source code of a PHP file when requested as .phps instead.
Some developers use .inc for files that are intended to be included using include or require. If the server is not configured to handle these as PHP as well, they will be delivered as plain text when they are requested directly.
But the developer can also be the source of vulnerability. For example when he uses a script for downloading files from the server and this script accepts nearly every input without validation.
If the file is served from a web server that has php interpretation enabled (via HTTP) then it will be processed. The only way you'd receive the code unprocessed is if PHP was disabled somehow.
I have encountered a mis-configured web server in the past that had one virtual host properly setup to server PHP files via the PHP interpreter. There was a second virtual host pointing at the same directory, but didn't have php enabled. This meant things like the 'config.php' for several apps where visible as plain text. As everyone knows a typical config.php has database auth credentials and other things that shouldn't be known.
So, it is very important to understand your web server setup, and make sure you aren't doing something silly.