2009-03-19 23 views
5

Estoy trabajando en un proyecto de php, y quiero ejecutar el código que se obtiene de una base de datos MySQL. No hay posibilidad de que se inyecte código inseguro, por lo que lo único que me preocupa es el rendimiento. ¿Debo usar eval() para poder ejecutar el código directamente o analizarlo para que call_user_func() lo ejecute?¿Debo usar eval() o call_user_func()?

Por ejemplo, si el código que obtuve fue "myfunc (1,2,3); anotherFunc (3,2,1);"
Puedo evaluar() directamente para ejecutar el código.

Pero para call_user_func(), tendría que analizar la cadena para que pueda ejecutarse. Entonces, ¿cuál es la mejor función para usar en este caso?

+0

Disculpe la edición, pero me llega una idea cada vez que veo que NO HAY OPORTUNIDAD de algo :) Siéntase libre de eliminarlo, si siente que no debería estar allí. –

+0

Lo sentimos, pero no es divertido ni instructivo. Simplemente un abuso de privilegios [en mi humilde opinión]. – soulmerge

+0

No hay ninguna posibilidad, ya que soy el único con acceso de escritura a la base de datos desde la que llama. – Drahcir

Respuesta

2

Como regla general, siempre trato de mantenerme lo más lejos posible de eval(). Este caso, sin embargo, parece un buen candidato para él.

Usted dice "No hay posibilidad de que se inserte código inseguro", por lo que la gran pregunta es: ¿hay alguna posibilidad de que el código que no funciona esté en la base de datos?

Si no es así, eval() es la solución, pero si existe un análisis adecuado, registro de errores, etc., puede ser una apuesta más segura. (Creo que usar call_user_func_array() es más rápido en teoría, por lo que cualquier sobrecarga de análisis podría volverse insignificante)

1

Creo que el análisis agregaría sobrecarga, pero la única manera de estar seguro es ejecutar pruebas. Pruébelo de ambas maneras con varias funciones y vea cuáles son sus resultados. Use un código que represente lo que espera almacenar.

¡Buena suerte!

1

Utilice eval(). Cualquier otra cosa no vale la pena, no tendrían ningún efecto secundario positivo.

1

Es posible que desee echar un vistazo a la extensión runkit, que puede ejecutar php en un entorno limitado que no afecta el código de ejecución.

Si el código se supone que afecta el código de ejecución, vaya a eval().

4

El almacenamiento de PHP en la base de datos es un mal olor de diseño en sí mismo; aunque en este caso está bastante seguro de que nunca puede contener un código inseguro, siempre es bueno minimizar la cantidad de suposiciones o defensas que tiene que hacer. Si almacena código PHP en la base de datos, entonces un ataque en el que un atacante obtiene acceso a su base de datos se vuelve mucho más grave, convirtiéndose en un ataque en el cual un atacante puede ejecutar código arbitrario. Sé que es muy improbable que su base de datos se vea comprometida de esta manera, pero no obstante, es una buena práctica de seguridad no permitir que ni siquiera una situación poco probable comprometa su sistema más de lo necesario.

Many people agree que eval() siempre se debe evitar, sin excepción, en el código PHP. Siempre hay una alternativa.

En este caso, sin embargo, creo que tendría que decir que usar eval() sería la mejor solución para usted, porque ya está almacenando código PHP en la base de datos, por lo que el uso de eval() no va para aumentar su riesgo más allá de eso.

lo haría, sin embargo, recomendamos que

  1. intenta validar el código antes de eval() que, por ser conservador en lo que permites. Supongamos que, de alguna manera, un atacante ingresó en su base de datos, aunque cree que eso es poco probable.
  2. Al menos piensa seriamente en reescribir su aplicación para que el código PHP no se almacene en una base de datos. Si está almacenando estructuras de datos complejas, piense en algo como JSON o incluso XML en su lugar. Los analizadores seguros existen para estos.

Lo siento si esta respuesta parece un poco reaccionaria; Siento que este tipo de cosas es muy importante.

0

También debe envolver el código que está a punto de ejecutar en un bloque try/catch, en caso de que haya un error (aunque haya dicho que no, existe la posibilidad, y es una buena práctica))