Cómo ejecutar PHP de forma segura desde una base de datos Mysql [cerrado]

Navega tus respuestas
1

Tengo una base de datos Mysql con una API vinculada a ella para llamar y ejecutar el código PHP almacenado en esa base de datos. Sí, has oído bien, el código PHP almacenado y ejecutado desde una base de datos Mysql. Entonces, esto es bastante serio desde el punto de vista de la seguridad, y ese es mi dilema. Tu primera sugerencia podría ser: "¡NO, mala!". No temas, se puede hacer. Hay algunas buenas razones para hacer esto.

  1. Aumento de velocidad de 40x (sin lecturas HD)
  2. Inyección de dependencia automática.
  3. Otros lenguajes de programación.

Seguridad.

El saneamiento de entrada "parece" ser lo más importante aquí, y mi filtro es de primera categoría. La inyección SQL sería tu peor pesadilla.

Mi pregunta es la siguiente: cuando se ejecuta código en vivo desde una base de datos, ¿se puede defender, se puede atacar? ¿Qué vectores de ataque podrían ser posibles? ¿Y cómo podrías defenderte?

En resumen, necesito un consejo experto, el peor de los casos, el mejor de los casos, haz esto, no hagas esto. Estás loco, algo.

ACTUALIZACIÓN1: Leeré todos los comentarios una y otra vez, La verdad importa.

  1. Estoy usando un clúster Percona mysql, se está produciendo una velocidad medible (almacenada en RAM)
  2. El control de versiones es fácil (y está integrado) Conseguí una tabla con L (idioma) FunctionName Vars Deps RequiredVars VERSION # etc ... etc.
  3. Yo agregaría para el nivel de interés, que una aplicación podría estar basada principalmente en enteros, en cuyo caso la entrada se puede limpiar mediante la conversión a (int) (IE. $ num = (int) $ _ GET ['s'];)
  4. Acojo con gran satisfacción las ideas, sugerencias y temas. Como creo que esto rompe muchas barreras al llegar a las nuevas y ahora estoy completamente dispuesto y dedicado a resolver esto, esa parte es un trato hecho; ¡Oh, la humanidad! Pero creo que esto PUEDE ser exitoso.
  5. Otro beneficio agregado es la neutralidad de idioma, ya que almaceno mi código en una base de datos, etiquetando un código como PHP y otro como RUBY o PYTHON, tiene usos serios. Nada que una pequeña acción de php-shellexec no pueda hacer hermosa (de nuevo teniendo en cuenta el perfecto saneamiento de entrada)

Continuaré actualizando (tengo una agenda ocupada, pero estaré tan atento como sea posible)

    
pregunta iGNEOS 27.12.2016 - 16:44
fuente

3 respuestas

5

Pensamientos generales

Esto parece una idea horrible para la producción. Si solo quieres probar cosas, ese es otro asunto.

Tampoco veo cómo es una ventaja. Respecto a tus puntos:

  1. ¿Dónde se encuentra tu db? ¿Por qué asumirías que no requiere lecturas de alta definición? Y si cree que los resultados de la base de datos se almacenan en RAM, ¿por qué no el código PHP de los archivos? ¿Y realmente has perfilado esto? ¿Para una gran escala? Asumiría una gran disminución de la velocidad (y eso ni siquiera está considerando cosas como no poder usar cachés de PHP).
  2. ¿De verdad? ¿Cómo? ¿Y no podrías simplemente usar una biblioteca para eso?
  3. ¿Qué? No creo que esto realmente cuente con un lenguaje neutral

También debe tener en cuenta que la depuración será bastante difícil, que es probablemente el mayor inconveniente. El desarrollo y la implementación de un nuevo código probablemente también será más difícil.

Amenazas

Las cosas de las que debe preocuparse con su enfoque:

  • Ser capaz de escribir en la base de datos de código llevará a la ejecución del código. Las escrituras pueden realizarse mediante inyección, o leyendo o forzando la contraseña de la base de datos (si un atacante puede conectarse a la base de datos).
  • Ser capaz de inyectar en las consultas de la base de datos de código SELECT conducirá a la ejecución del código.

Mitigaciones

De todos modos, si aún quieres hacer esto (sugerencia: no), hay algunas cosas que puedes hacer para hacerlo un poco más seguro:

  • Almacene su código PHP en una base de datos separada, accesible con un usuario diferente. El usuario que recupera datos normales de la base de datos no debe tener acceso a esta base de datos.
  • No permita el acceso remoto a la base de datos de códigos, y obviamente use una contraseña segura. No utilice elementos como phpmyadmin, que en realidad permitiría el acceso remoto a la base de datos.
  • No coloque la entrada del usuario en las consultas que se ejecutan en la base de datos de códigos.
  • Lo ideal es no realizar consultas en esta base de datos en todo el lugar. Probablemente solo necesite una o dos funciones que seleccionen el código que desea. Use declaraciones preparadas para esos.
  • Piense solo en dar acceso de lectura al usuario de la base de datos de códigos a la base de datos de códigos (si esto tiene sentido en el contexto de su aplicación).

Además, la defensa adecuada contra la inyección de SQL no es el saneamiento o el filtrado de entrada ( saldrá mal ), sino declaraciones preparadas. La entrada de lanzamientos a ints es excelente como defensa en profundidad, pero en la práctica es miserable como única defensa. He visto muchas aplicaciones que adoptan ese enfoque (además de ecaping / filtering for non-int), y nunca sale bien.

Supuse que almacena su código PHP en la base de datos y lo ejecuta con eval, pero es probable que la mayoría de los puntos se apliquen también a otros enfoques.

    
respondido por el tim 27.12.2016 - 17:13
fuente
2
  

Aumento de velocidad de 40x (sin lecturas HD)

OMG, NO.

Sitieneunaconfiguraciónenlaqueelcódigoqueseleeenlabasededatosseejecuta40vecesmásrápidoqueelcódigoqueseleeenlosarchivos,esaconfiguraciónserompefundamentalmente.Elhechodequenosepaestoyamehacepensarquenoestánicercadeestarlistoparaprobaralgotanesotéricocomoloquedescribe.

AmenosquehayareescritoelcargadordePHPosuinterfazalcachédecódigodeoperación,entoncesanalizaráycompilará(yoptimizarásiestáusandoelcachédememoriadeZend)cadavezqueobtengaelcódigodelabasededatos.Siestoseejecutamásrápidoqueleerlosarchivosdelsistemadearchivos,entoncesnotieneuncachédecódigodeoperación,estámuymalconfigurado,tienealgunosproblemashorrendosconsusistemadearchivosoelalmacenamientoencachédeVFS.Algoestámuy,muymal.

  

Inyeccióndedependenciaautomática

No.Nohayformadequeelsistemasepamágicamentecómoesladependenciadesucódigo.Esposibledefinirunmarcoqueguardeestodemaneraefectiva,peroestotambiénesposiblesintenerquemantenersuPHPenunabasededatos.

  

Otroslenguajesdeprogramación.

¿Quépasaconellos?Lamayoríadeloslenguajesdeprogramaciónlepermitencrearconstruccionesqueinvocancódigoescritoenotroslenguajes.TantoPHPcomoMySQLpuedenllamarabibliotecascompartidasquesehanescritodeunamaneraquepuedeserinvocadaporelmismohilo/proceso.Peroestorealmenteesalgodecienciaespacialymuypeligrososinosabesloqueestáshaciendo(esbastantepeligrosocuandosabesloqueestáshaciendo).PHP,porotrolado,vieneconmuchasextensionesbienescritasparamanipulardatos(cifrado,manejodeimágenes,funcionesdered...).MuchosmásqueMySQLhace.Tambiénvieneconsoporteparainvocarotrosprocesosconcomunicaciónuniobidireccional.

  

Elsaneamientodeentrada"parece" ser lo más importante aquí, y mi filtro es de primera clase

Debería validar la entrada y sanear . Aquí le daré el beneficio de la duda y asumiré que se refiere a la entrada al sistema en su totalidad y no solo a un nivel. Sin embargo (si sus justificaciones fueran válidas) gritaría muchísimo a cualquier persona que trabaje para mí que almacenó código ejecutable accesible / modificable por la misma cuenta que accedió / modificó los datos en la base de datos. Incluso entonces esto conlleva enormes riesgos de inyección / modificación de código.

  

basado principalmente en enteros

= no solo basado en enteros. Espero que estés usando un método mejor en el que la entrada pueda sea algo distinto a un entero.

Las únicas razones remotamente justificables en las que puedo pensar para intentar una arquitectura de este tipo son:

  • donde se proporciona una función (muy en caja de arena) para ejecutar el código enviado por el usuario en
  • donde desea proporcionar un mecanismo para la administración de cambios en una granja de servidores de gran tamaño (pero aquí nuevamente me gustaría tener problemas con la arquitectura por ser ineficiente, peligrosa e ineficaz mientras se puede lograr usando un código almacenado en archivos).
respondido por el symcbean 28.12.2016 - 00:31
fuente
1

No veo que sus ventajas mencionadas sean válidas y, por lo tanto, el costo es el siguiente: algunas de las amenazas y desventajas a las que debe prestar atención:

  1. A medida que aumenta su base de datos, su velocidad de recuperación es más lenta y más lenta, lo que afectará a todo el rendimiento del sitio web, especialmente cuando tendrá una recuperación anidada: al igual que su código en la base de datos es accediendo de nuevo a la base de datos para otros datos!

  2. Muy difícil de mantener su código:

    • La edición es costosa: para cambiar un carácter en su código, debe actualizar todo el texto del código a través del comando SQL.
    • La prueba es costosa: por cada cambio o falla, debe actualizar todo el texto a través del comando SQL.
    • La depuración es imposible.
    • No hay soporte desde el control de versiones de origen (SVN, GIT, CVS..etc).

  3. Sin control de permisos , por lo que necesita tener más controles de acceso y autorización en el nivel de DB, lo que es más costoso y más difícil de implementar.

  4. Problema de disponibilidad si el DB no está disponible.

  5. Si tiene una pérdida de base de datos, también tendrá pérdida de código , lo que puede revelar más información y puertas a su infraestructura.

  6. Los ataques de inyección de código serán más fáciles y tendrán un mayor impacto ... imagina que solo se carga una shell mediante inyección SQL.

  7. Sin auditoría o última modificación para verificar si se modificó algún código sin su conocimiento.

respondido por el Opaida 27.12.2016 - 18:34
fuente

Lea otras preguntas en las etiquetas

¿Afecta la COW sucia al núcleo de OSX? Codificación para detectar DDOS [cerrado]