I have a script that users can input a image URL (from another website) and then crop it using JS and have it saved on my server.
My question is... when getting the image from another server is it safer to use CURL or allow_url_fopen (via file_get_contents())? Or is there a preferred/safer method available?
Security is a big concern for me as I know this is a very dangerous procedure - The script will only need to work for image files if that makes a difference.
Thanks
curl's error handling is much better than file_get_contents(). If you care about that, curl's probably the way to go. If a simple "oops, that didn't work" is enough for you, though, file_get_contents() is a perfectly acceptable shortcut.
First of all, if you want to get into a deep security discussion. Downloading files is in fact a security concern if you don't know what you are doing.
You can overwrite vital files or even overwrite system files in some cases. Uploading scripts,etc on the server with intention of executing them via web server is also an issue.
So it's not sunshine and rainbows like people pointing out here.
Back to your question, allow_url_fopen is a configuration directive. I assume you meant file_get_contents(). Either will do fine. As others pointed out Curl is a bit more verbose and it's also faster.
If you do end up using file_get_contents(), make sure you never include an unfiltered variable as a parameter.
Downloading a file is not a security concern at all, no matter whether it's your server or your own computer, or the application/code you are using to download it :) It's whether you are executing the file :D
All you have to do is just make sure you are not going to EXECUTE / INCLUDE anything in the file. Since you are only going to crop the image, I think you are good to go :)
I suggest cURL tho, allow_url_fopen may raise security problems in other places in your code.
cURL has more options ans possibilities.
Both are equally safe (or unsafe if misused).
It is wiser to use cURL because you will uprise your experience with a more powerful function, which may serve you in future projects.
Also, if this very project needs new functionalities later on, you will not have to rewrite everything with cURL if file_get_contents is not enough.
The answer of this thread shows a nice cURL function: Replace file_get_content() with cURL?
curl would generally be a safer way. It'd take an explicit design/coding decision on your part to allow the results from curl to directly affect your program, whereas allowing urls in the f*() functions would let
include('http://example.com/really_nasty_remote_takeover.php');
occur without error.
Related
I just wanted to keep all my code libraries (PHP Classes; ex: http://libraries.com/form.php) on a single server for easy maintenance and availability. Wherever I need to use this library; I'd just include it in my code. But; I know; enabling remote URL include isn't safe at all. So I found a work around.
I'd just use eval( file_get_contents( 'http://libraries.com/form.txt' ). I use .txt instead of .php so I get PHP code as it is; not a blank file returned by server after PHP is processed.
This works; I get my PHP library/class and I can play with it on a remote location. But I don't know if it is safe or not. What could be pros and cons of this way. Or what other way you can suggest me to achieve this safely?
This:
Has all the security downsides of includeing remote files
Is massively inefficient due to all the extra HTTP requests
Means that a new release of a library gets deployed without being tested against the rest of the code in an application
Adds an extra point of failure for the application
Don't do this. It is a terrible idea.
Installation of dependencies should be a feature of your install script, not the application itself.
I'm having many websites installed on the same webserver. What i wanna do, is to be able to include a same file from different websites as
<?php include '/home/site/www/path/to/file.php'; ?>
and in the same time block functions like highlight_file and file so using the following code won't displays my files content
<?php echo hightlight_file('/home/site/www/path/to/file.php'); ?>
Any help will be appreciated.
If you want your PHP files to be runnable but be safe from being read, your best option is to encode them.
Take a look at IonCube PHP Encoder and SendGuard , they are both very popular options to protect source code.
Blocking PHP function can work, but you'll never be safe because you can forget functions (can you reall list them all? What if there's one you actually need?), or new functions could be added in the future and if you do not block them you'd be exposed.
...so using the following code won't displays my files content
Does that mean you want to allow other people to deploy code on the server which calls your code without revealing the PHP source? If so, then disabling highlight_file isn't going to help much. You also need to disable include, require, fopen, file_get_contents, the imap extension and several other things - which means they won't be able to access your code at all.
If you're letting other people whom you don't necessarily trust deploy code on your server then there are lots of things you need to do to isolate each account - it's not a trivial exercise and well beyond the scope of an answer here. But it's not really possible to allow access to a shared include file without providing access to the source code. Using encoded PHP solves some problems but introduces others. A better solution is to expose the functionality via a web or socket API (this solves the sharing problem but not the isolation problem).
for security reasons I have disabled the function glob in the php.ini and it works as expected, but I also noticed that phpinfo reveals the following information:
Registered PHP Streams: php, file, glob, data, http, ftp, zip, compress.zlib, phar
So if I take following source:
$it = new DirectoryIterator("glob://C:\wamp\www\*");
foreach($it as $f) {
printf("%s: %.1FK\n", $f->getFilename(), $f->getSize()/1024);
}
It would still return the contents of the specified directory.
How can I globally unregister PHP Streams such as glob?
The short answer is: don't even bother trying.
PHP is a complete enough language that if someone is going to write dirty of vulnerable code, they can do it through any block you put in place. The only thing disabling functions like that does is make application developers' lives hell.
It's been proven that things like safe_mode and open_basedir don't actually secure anything. The reason is twofold:
Black lists (which is what safe_mode is) don't work. This has been proven over and over and over.
You can't secure on top of an insecure base. It's already too late. PHP itself already has enough access that even if you disable all the fun parts, people can still get around it.
Instead, protect from the bottom up. Install a chroot jail, and run PHP inside that. Use proper permissions. Vet the code that you run on your server. Monitor the server for intrusions. Nothing fancy. Just good old fashioned sys-admin work...
To answer your original question
The only way that you can unregister a stream wrapper is to do it yourself via stream_wrapper_unregister(). You could use an auto-prepend-file to do it for you (to run that code before every script).
But realize that it's trivial to implement glob in PHP. So there really isn't much point in disabling it...
i use file_get_contents function to grab data from sites and store the data in database. it will be very inconvenient for me, if one day the script will start not working.
I know, that it can start not working, if they change the structure of site, but now i'm afraid, that maybe there are mechanisms to disable the working of this function, maybe from server?
i tried to find documentation about it, but can't get, so maybe you will help me?
Thanks
I know, that it can start not working,
if they change the structure of site,
but now i'm afraid, that maybe there
are mechanisms to disable the working
of this function, maybe from server?
Yes, it can be disabled from php.ini with allow_url_fopen option. You have other options such as CURL extension too.
Note also that you will need to have openssl extension turned on from php.ini if you are going to use the file_get_contents function to read from a secure protocol.
So in case file_get_contents is/gets disabled, you can go for CURL extension.
It is possible to disable certain functions using disable_function. Furthermore the support of URLs with filesystem functions like file_get_contents can be disabled with allow_url_fopen. So chances are that file_get_contents might not work as expected one day.
There are at least two PHP configuration directives that can break your script :
If allow_url_fopen is disabled, then, file_get_contents() will not be able to fetch files that are not on the local disk
i.e. it will not be able to load remote pages via HTTP.
Note : I've seen that option disabled quite a few times
And, of course, with disable_functions, any PHP function can be disabled.
Chances are pretty low that file_get_contents() itself will ever get disabled...
But remote-file loading... Well, it might be wise to add an alternative loading mecanism to your script, that would use curl in case allow_url_fopen is disabled.
I am interested in finding the most reliable method for uploading files in PHP. I need a progress bar with the upload.
I have tried SWFUpload but it randomly issues an I/O Error. Even if the same file is uploaded sometimes there is an error and sometimes there is not. I have configured all the necessary INI/Mysql/Apache directives to accept large file uploads.
So, I am looking for alternatives as a Flash based solution has not worked. Would Java be more reliable? I have also looked into PHP with APC.
I definitely cannot afford these random errors, so any help on reliable software / suggestions on how to minimize them would be appreciated.
Thank you.
There are other flash based solutions other than SWFupload. Have a look at uploadify.com
I haven't come around to try this myself yet but http://www.plupload.com/ might be what you're looking for on. But otherwise PHP + APC works good as well.
I am assuming 2 things here:
1) Some kind of client will be doing the file upload
2) You get some kind of say on what the client installs on their computer to help make this happen.
If this is the case, my first suggestion would be:
Give them FTP or SFTP client software to upload files. The php page you make can have a link to Filezilla, along with instructions on how to use it. ftp and sftp are THE protocols to use for transferring files. HTTP is just not designed(well) for it, nor are browsers.