php的本机函数与未经过滤的输入一起使用有多安全？

Question

Maybe I am being a bit paranoid, but as I am re-writing a contact module, the following question came to mind:

Can I use unfiltered input in php's native functions?

It is easy to sanitize stuff to put in a database, output to the screen, etc. but I was wondering if for example the following statement could be dangerous:

    if (file_exists($_POST['brochure'])) {
        // do some stuff
    }

If someone somehow managed to post to that page, could the above code be exploited?

The above code is just an example, I can think of other functions I use when processing a form.

Edit: Thanks everybody, the file_exists in the example is actually part of a sanitation function but when cleaning up, php functions are being used so it is rapidly becoming a chicken and egg story: To use functions, I have to clean up, but to clean up I have to use functions.

Anyway, I have got some fresh ideas now.

Answer 1

Yep. All I'd have to do is post "/etc/passwd", or "includes/dbconnection.php" (or anything) to your page, and depending on what //do some stuff actually is, I could possibly delete, modify or read sensitive information. The file_exists function itself won't do anything you wouldn't expect, but you can expect malicious users exploiting your logic.

Always sanitise your user input. Always. If you're expecting to only grab files from one particular folder, don't allow .. or / in the input

Answer 2

By itself, that looks reasonably safe, but it could be used to reveal information. It could allow an attack to check for the presence (or absence) of particular files (eg /etc/passwd , /proc/* , etc).

So in this example, you should ensure that $_POST['brochure'] is sanitised first to only accept inputs that match potentially valid file names. Drop any input that contains .. , or that starts with a / .

Other functions could have potentially much worse side effects...

Answer 3

PHP's builtins won't do "unexpected" things on bad input (eg, file_exists("foo; rm -r /") will say "no, the file 'foo; rm -r /' doesn't exist")... And if they do, that's a bug you can file against Zend.

Of course, this doesn't stop people from exploiting your code (eg, file_exists("../hidden/shell.php") ), so you should still (actually, you should always ) be careful when passing user-supplied input around.

Answer 4

could 'brochure' = '../../../../.htaccess'

that's an interesting question.

Apache on my computer is set to deny listing or viewing .ht* and .ini and .php.inc files, but you have me worried now.

Answer 5

你应该养成过滤所有输入的习惯，但是你可能想查看http://www.hardened-php.net/ ，它分发了一个强化补丁和'Suhosin'，它默认存在于许多二进制发行版中（ OpenSUSE，Mandriva和Debian / Ubuntu）

Answer 6

The fact that you have to ask is your answer. It's not safe.

file_exists() is not as bad as others, but if you don't see the source code for the function you're passing data to, and know how it handles user input, then you're taking a chance.

It's not a good idea to pass unfiltered user data into any php filesystem command. The key with security is that you never allow input to context switch. In this case, your minimum sanitization should be removing path characters.

Always assume a hostile user and the worst they could possibly do if they saw your source code.

Answer 7

多年来，在PHP本身的源代码中发现了安全漏洞，因此函数可以缓冲溢出流式攻击Suhosin是一个修补PHP以消除一些风险的项目。

Answer 8

I wouldn't trust those functions at all.

This may definitively sound strikingly, however when I closely watch the people and their C code quality in the commits, reverts, etc. over the last eight years, I'm just in constant fear.

Answer 9

What happens with the database string is that it could be retrieved and used somewhere that has a vulnerability. For the answer to your question, think about removing the step where you store the string and then retrieve it. You use it right away, and you have the same risks.