¿Hay alguna posibilidad de que los desarrolladores de PHP implementen puertas traseras en el núcleo de PHP?

6

Esto no es una preocupación que yo personalmente tengo, ¡no! En mi entorno laboral, he escuchado de programadores y no programadores que los desarrolladores de PHP siempre ponen en secreto las puertas traseras de PHP a las que nadie tiene acceso sino a sí mismos, por lo que si un proyecto se pone en marcha y se convierte en un gran proyecto, pueden hacer lo que quieran con él. , como robar los activos de la empresa y etc. Aunque respeto a todos los desarrolladores de PHP en php.net y otros, me gustaría conocer sus opiniones.

P.S: como algunos virus, incluido Starex, que se habilitaron mediante una acción específica.

    
pregunta ALH 18.05.2012 - 03:27
fuente

4 respuestas

9

Backdoor are . Esto no es de ninguna manera algo exclusivo de PHP, y puede suceder por una serie de razones. Los proyectos de código abierto no son totalmente inmunes, ya que el código puede ser muy poco inteligente , sin embargo, esto no es algo que solo afecte a la fuente abierta proyectos

Por ejemplo, Horde (php) fue pirateada y el atacante introdujo a backdoor , pero lo mismo le sucedió a VSFTP (C / C ++) . A veces, el proveedor de software colocará intencionalmente una puerta trasera en su propio código. Se cree que esto le sucedió a Sistemas SCADA de RuggedCom , que es de código cerrado.

Los gusanos pueden contener una puerta trasera. Por ejemplo, MyDoom era un gusano de correo electrónico que se extendió y abrió un puerto que permitía la ejecución de código. Más tarde, un gusano llamado DoomJuice se propagó utilizando la puerta trasera de MyDoom . Además, las verdades de la familia PhatBot / AgoBot de bots IRC difunden el respaldo en la puerta trasera de MyDoom, lo que permite que cualquier adolescente con un compilador de C ++ se aproveche de él.

Es fácil dejar de lado descuidadamente una rutina de saneamiento, ¿quién puede decir que es una puerta trasera?

    
respondido por el rook 18.05.2012 - 03:38
fuente
4

PHP es considerado un lenguaje inseguro para desarrollar, no por las puertas traseras secretas instaladas por los desarrolladores de lenguajes PHP, sino porque inicialmente fue desarrollado sin la seguridad como una preocupación importante y comparado con otros lenguajes / marcos web, es difícil de desarrollar de forma segura en ella.

Por ejemplo, si desarrolla una aplicación web LAMP / LAPP (linux + apache + mysql / postgresql + PHP), debe codificar manualmente el saneamiento de entrada / salida para evitar la inyección de SQL / XSS / CSRF, asegúrese de que no haya las llamadas sutiles al código proporcionado por el usuario eval (como en preg_replace con un '/ e' que termina el argumento de expresión regular), manejan de manera segura las cargas de archivos, se aseguran de que las contraseñas de los usuarios estén bien ocultas (no en texto sin formato), las cookies de autenticación son indiscutibles , seguro (https) y solo http, etc.

La mayoría de los marcos web modernos simplifican muchos de estos problemas al hacer la mayoría de estas cosas de manera segura (o al principio hacerlo de forma insegura y luego obtener actualizaciones seguras).

El riesgo de que haya una puerta trasera secreta en un PHP de código abierto es pequeño; y el riesgo está presente en cada pieza de software (windows / linux / apache / nginx / IIS / postgresql / oracle) que utilice, tanto de código abierto como de código cerrado. Los de código abierto al menos tienen el beneficio que muchos ojos independientes lo miran todo el tiempo y usted podría examinarlo si lo desea.

También tenga en cuenta que en principio, incluso después de examinar completamente el código fuente y no encontrar puertas traseras y examinar completamente el código fuente de su compilador (no encontrar puertas traseras), si luego vuelve a compilar su compilador (bootstrap usando un compilador existente no confiable) y luego compile el código fuente seguro con su compilador "seguro" recién compilado, su código ejecutable aún podría tener puertas traseras desde el uso del compilador existente no confiable para compilar el nuevo compilador. Consulte las Reflexiones sobre la confianza en Kenia de Ken Thompson. (La forma en que esto se defiende en la práctica es mediante el uso de muchos compiladores independientes y oscuros de múltiples fuentes para compilar cualquier compilador nuevo y luego comparar la salida).

    
respondido por el dr jimbob 18.05.2012 - 16:56
fuente
1

Como desarrollador de PHP, sé que poner puertas traseras es muy simple si el desarrollador lo desea o, a menudo, se implementa involuntariamente si al desarrollador no le importa la seguridad y recuerda que existe más adelante.

    
respondido por el kbec 18.05.2012 - 15:33
fuente
1

Algo como esto podría ser posible, pero se descubriría en proyectos de código abierto a lo largo del tiempo. PHP es de código abierto y puede utilizar los beneficios. Si tienes miedo en las puertas traseras, descarga la fuente, léela y compílala tú mismo. Además, sugiero utilizar los paquetes de su distribución. El mantenedor del paquete php encontraría una puerta trasera de este tipo en el sentido ascendente. Si no confía en su mantenedor, descargue la fuente y léala antes de compilarla usted mismo.

Pregunte a estas personas sobre la ubicación de la puerta trasera. Si están tan seguros de que php está bloqueado, no debería haber ningún problema para mostrarle las líneas de código.

    
respondido por el sfx 18.05.2012 - 15:58
fuente

Lea otras preguntas en las etiquetas