¿Qué tan seguras son las funciones nativas de php para usar con entradas no filtradas?

Question

Tal vez estoy siendo un poco paranoico, pero ya que estoy re-escritura de un módulo de contacto, la siguiente pregunta vino a la mente:

¿Puedo utilizar la entrada sin filtrar en funciones nativas de PHP?

Es fácil de desinfectar cosas para poner en una base de datos, salida a la pantalla, etc, pero me preguntaba si, por ejemplo, la siguiente declaración podría ser peligroso:

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

Si alguien de alguna manera para publicar a esa página, ¿podría explotarse el código anterior?

El código anterior es solo un ejemplo, puedo pensar en otras funciones que uso al procesar un formulario.

Editar: Gracias a todo el mundo, los file_exists en el ejemplo es en realidad parte de una función de saneamiento pero cuando la limpieza, se utilizan las funciones de php por lo que se está convirtiendo en una historia huevo y la gallina: Para utilizar las funciones, tengo para limpiar, pero para limpiar tengo que usar funciones.

De todos modos, tengo algunas ideas nuevas ahora.

Answer 1

Sí. Todo lo que tendría que hacer es publicar "/ etc/passwd", o "includes/dbconnection.php" (o cualquier cosa) en su página, y dependiendo de lo que realmente sea //do some stuff, podría eliminar, modificar o leer información confidencial. . La función file_exists no hará nada que no esperaría, pero puede esperar que usuarios malintencionados exploten su lógica.

Siempre esterilizar su entrada del usuario. Siempre. Si usted está esperando sólo para agarrar los archivos de una carpeta en particular, no permiten .. o/en la entrada

Answer 2

podría 'folleto' =' ../../../../.htaccess'

que es una pregunta interesante.

Apache en mi computadora está configurado para denegar el listado o ver los archivos .ht * y .ini y .php.inc, pero me preocupa ahora.

Answer 3

órdenes internas de PHP no lo harán "inesperados" cosas malas en la entrada (por ejemplo, file_exists("foo; rm -r /") dirán "no, el archivo 'foo; rm -r /' no existe") ... Y si lo hacen, es un error que puedes presentar contra Zend.

Por supuesto, esto no La gente deja de explotar su código (por ejemplo, file_exists("../hidden/shell.php")), por lo que debe todavía (en realidad, usted debe siempre ) tenga cuidado al pasar la entrada proporcionada por el usuario alrededor.

Answer 4

Por sí solo, parece razonablemente seguro, pero podría usarse para revelar información. Podría permitir que un ataque verifique la presencia (o ausencia) de archivos particulares (por ejemplo, /etc/passwd, /proc/*, etc.).

Por lo tanto, en este ejemplo, debe asegurarse de que $_POST['brochure'] se desinfecte primero para aceptar únicamente entradas que coincidan con nombres de archivo potencialmente válidos. Elimine cualquier entrada que contenga .., o que comience con /.

Otras funciones podrían tener efectos secundarios potencialmente mucho peores ...

Answer 5

realmente debería estar en el hábito de filtrar todas las entradas, pero es posible que gustaría ver http://www.hardened-php.net/ que distribuye un parche endurecimiento y 'Suhosin', que se encuentra en muchas distribuciones binarias de forma predeterminada (OpenSUSE, Mandriva y Debian/Ubuntu)

Answer 6

El hecho de que usted tiene que preguntarse es su respuesta. No es seguro.

file_exists() no es tan malo como otros, pero si no ve el código fuente de la función a la que le está pasando los datos, y sabe cómo maneja la entrada del usuario, entonces se está arriesgando.

No es una buena idea para pasar datos de usuario sin filtrar en cualquier comando php sistema de archivos. La clave con la seguridad es que nunca permite la entrada al cambio de contexto. En este caso, su desinfección mínima debe eliminar los caracteres de ruta.

suponer siempre un usuario hostil y, posiblemente, el peor que podría hacer si veían a su código fuente.

Answer 7

A lo largo de los años se han encontrado vulnerabilidades de seguridad en la fuente de PHP, de modo que las funciones eran susceptibles de ataques de estilo de bufferoverflow Suhosin es/era un proyecto que parcheaba PHP para eliminar parte del riesgo.

Answer 8

¿Qué ocurre con la cadena de base de datos es que podría ser recuperada y utilizada en alguna parte que tiene una vulnerabilidad. Para la respuesta a su pregunta, piense en eliminar el paso donde almacena la cadena y luego recupérela. Lo usas de inmediato, y tienes los mismos riesgos.

Answer 9

yo no confiaría en aquellas funciones en absoluto.

Esto puede sonar definitivamente llamativo, sin embargo, cuando observo de cerca a las personas y su calidad de código C en los commits, reverts, etc. en los últimos ocho años, tengo un miedo constante.