No es tanto que PHP en sí tenga problemas de seguridad (suponiendo que se necesiten las actualizaciones de seguridad), ya que existe una gran cantidad de software popular basado en PHP con problemas de seguridad rampantes. Podría criticar a PHP por ser un lenguaje que le da suficiente cuerda para ahogarse, pero el problema real es qué tan prevaleciente es el código PHP vulnerable. Uno no necesita mirar más allá de la etiqueta PHP de desbordamiento de pila para encontrar novatos en PHP que escriben códigos horriblemente vulnerables basados en la atrocidad de un antiguo tutorial.

Además, un número significativo de software PHP popular conocido por sus fallas de seguridad rampante se basa en el código muy antiguo y las prácticas de codificación. Muchas de estas prácticas antiguas se consideran malas prácticas debido a problemas de seguridad inherentes.

  

Esto, para mí, parece decirle a alguien que nunca maneje para que no sufran un accidente automovilístico.

Bastante sí. Un mejor consejo podría ser: "no conduzca un automóvil viejo sin airbags".

  

Mi instinto es que el host está tratando de echar la culpa al cliente por fallas de seguridad en su propio sistema.

No necesariamente. Si un usuario usa la misma contraseña para el sitio de WordPress y cPanel, comprometer la contraseña de WordPress también compromete a cPanel. Eso sería culpa del usuario. Sin embargo, los hackers rara vez necesitan llegar tan lejos, y solo usan un shell de PHP.

  

Le dije a mi cliente que para procesar el formulario de contacto necesitarán algún tipo de script dinámico. (¿Falso?)

No necesariamente es cierto. Puede utilizar un servicio de terceros para gestionar el envío de correo. Luego, el servicio maneja los scripts del servidor dinámico y asume las implicaciones de seguridad. Existen numerosos servicios de este tipo disponibles con diferentes conjuntos de características, y son populares para impulsar formularios de contacto en sitios generados estáticamente.

  

¿Qué tan cierta es la afirmación de que el uso de cualquier script PHP, no importa lo sencillo que sea, es un problema de seguridad inherente?

Algunos, pero no mucho. PHP involucra algún código activo, tanto en PHP como en el software del servidor que lo ejecuta. Si alguna vez hubo una vulnerabilidad de seguridad en ese proceso que no dependiera de un código PHP específico, podría ser explotada. Si bien ese riesgo es mínimo, es un riesgo que un servidor sin tal soporte no tenga.

"Derecho" puede no ser la palabra correcta, pero "sabio", "prudente" y "concienzudo" vienen a la mente. PHP, desde su inicio, se ha adherido a una filosofía que devalúa la corrección en el software. Hay un gran número de situaciones que un programa puede encontrar donde otros lenguajes (por ejemplo, Python) se rendirían y arrojarían un error para decirle que su programa es incorrecto, pero PHP en cambio elige hacer algo sin sentido y continúa como si las cosas fueran simplemente bien.

Tenga en cuenta que corrección es muy importante para la seguridad. Un lenguaje que es propenso a ignorar silenciosamente los errores de la izquierda y la derecha tendrá más que una buena cantidad de programas con problemas de seguridad. Por ejemplo, es posible que tenga un código que sus programadores creen que protege contra cierto ataque, pero de hecho se omite porque el intérprete ignora un error.

Además:

• PHP está diseñado para atraer al denominador más bajo de programadores con la menor motivación para ser buenos en su oficio. Y, por lo tanto, es más probable que escriban software inseguros.
• El equipo de PHP tiene un historial de intentos profundamente fallidos de solucionar problemas comunes de seguridad. Busque, por ejemplo, la protección de inyección SQL, que traiciona repetidos intentos fallidos de solucionar el problema: real_escape_string (porque el escape_string original se rompió, pero no lo eliminaron hasta más tarde) vs. addslashes vs. mysql_escape_string / pg_escape_string y así sucesivamente. Mientras que casi todos los demás lenguajes solo incluían declaraciones preparadas y parámetros de consulta y obtuvieron un diseño extensible a todas las bases de datos desde el primer intento.

Así que para todas las respuestas en otras respuestas sobre cómo puedes escribir software seguro en PHP, si lo intentas, estarás muy en contra de la corriente.

Los problemas de seguridad de PHP generalmente se pueden reducir a dos categorías

Sistemas no parcheados

A partir de ahora, Estadísticas de Wordpress muestra que más de la mitad de los usuarios ejecutan PHP en versiones de PHP pasadas < a href="http://php.net/eol.php"> End of Life (PHP 5.2 - 5.4). En dos semanas, PHP 5.5 se convierte en EOL y luego salta a aproximadamente el 80% de todas las instalaciones. Ahora, para ser justos, algunas instalaciones de Enterprise / LTS Linux darán soporte a las correcciones de seguridad, pero la gran mayoría de ellas no están usando correcciones con portada posterior (o algunas no aplican parches a sus sistemas). Peor aún, mucha gente se niega a actualizar PHP en sí. O no pueden / no quieren actualizar su código, o creen que el software anterior es más estable.

Wordpress (la aplicación PHP número 1 que se usa en todo el mundo) hizo un esfuerzo concertado para asegurarse de que los usuarios se mantengan actualizados con el software en sí (y han hecho grandes avances), pero a pesar de eso, solo el 40% está ejecutando la última versión de WordPress. Eso significa que un 60% puede tener una vulnerabilidad de seguridad sin parches. Y eso es sólo el programa base. Wordpress tiene un enorme ecosistema de complementos, y muchos de ellos tienen vulnerabilidades de seguridad propias .

Luego hay otros problemas, como muchos códigos antiguos que utilizan el biblioteca mcrypt . Y eso es solo un complemento de PHP que puedes compilar.

Ahora, extrapola esto a los servidores que no se están ejecutando y que reportan estadísticas a WP. No pinta un cuadro bonito. El verano pasado encontré un sitio web con una página de comercio electrónico que todavía estaba en Apache 1.3.3 y PHP 4.1.2. Era tan viejo que tenía SSLv2 habilitado ...

malas prácticas

Si se mantiene el tiempo suficiente con las preguntas de PHP, verá que muchas personas practican códigos incorrectos. Algunos de los problemas que he visto a lo largo de los años

• Inyección SQL
• Pensar en MD5 es una buena manera de proteger contraseñas
• Uso de API obsoletas en su código (es decir, ext/mysql , el antiguo conector MySQL)
• Confiando en la entrada del usuario para ejecutar el código (es decir, utilizando eval con los datos proporcionados por el usuario)
• No desactivar los riesgos de seguridad en el código PHP (es decir, la función exec )

Para los no entrenados, esto parece un problema de PHP, cuando son los codificadores y sus ecosistemas los que producen los problemas. Tal vez tenían prisa. Tal vez contrataron a un tipo que hace esto en su tiempo libre y "simplemente lo hizo funcionar".

¿Puede ser seguro?

SI! Pero esa seguridad requiere un poco de esfuerzo. Mantenga su instalación de PHP actualizada. Heck, mantenga todo su servidor al día. Host no hará seguridad y parches? Encuentra otro anfitrión. (Me sorprende la gente que se resiste a esto). Construye tu propio servidor (las máquinas virtuales son baratas). Pero sobre todo, prestar atención. Aprende todo lo que puedas sobre seguridad. No deje que su sitio web y su servidor salgan al mar.

Alguien que te dice que PHP es inseguro es simplemente perezoso.

PHP no es menos, ni más seguro, ni inseguro que cualquier otro idioma (Java, Rails, etc.). Se trata de la codificación. ¿Hay controles y balances en su lugar para desviar, defender, prevenir y mitigar un ataque? Cotización:

  

WhiteHat Security realizó evaluaciones de vulnerabilidad de más de   30,000 sitios web que utilizan .NET, Java, ASP, PHP, Cold Fusion y Perl. los   Los lenguajes más utilizados fueron .NET (28.1 por ciento de los   aplicaciones), Java (24.9 por ciento) y ASP (15.9 por ciento).

     

...

     

El lenguaje de programación .Net tenía un promedio de 11.36 vulnerabilidades   por slot, Java 11.32 y ASP 10.98. El lenguaje más seguro,   ColdFusion, tenía seis vulnerabilidades por slot. Perl tenia siete   Las vulnerabilidades por slot y PHP tenían 10.

     

...

     

Java representó el 28 por ciento de las vulnerabilidades encontradas y ASP 15   por ciento. “De nuevo, el número de solicitudes escritas en el idioma   Junto con las complejidades de los sitios web tiene que ser considerado como un   factor contribuyente ”, señala el informe. PHP también representó 15   Porcentaje de vulnerabilidades descubiertas. ColdFusion solo representó 4   Porcentaje de vulnerabilidades y Perl 2 por ciento. ( fuente )

Esto no dice nada sobre cómo se desarrollaron los sitios en términos de buenas prácticas de codificación. Por ejemplo, si tomó programadores no calificados (por falta de mejores términos) en cada idioma, estos números podrían revertirse y perl podría tener la mayoría de las vulnerabilidades, con .Net tener la menor. Todo se reduce a lo que se supone que hace el propio código. ¿Se ha programado el código para realizar su única función con la manipulación / abuso probado antes de que se pusiera en desarrollo?

Hay mucha seguridad hojas de trucos , guías de mejores prácticas , y otras reseñas que cubren problemas de seguridad pero esto se convierte en una situación en la que el cliente está cansado según los consejos de su proveedor. Esto puede ser un obstáculo, ya que se convierte en un "dijo él", dijo que le costó convencer a su cliente para que le permita crear el sitio usando PHP. Un método que podría usar si todavía quisiera usar PHP sería crear un sitio de demostración, luego usar un escáner de evaluación de vulnerabilidades (Acunetix, AppScan, Burpsuite) en su contra para detectar fallas. Si no se encuentra ninguno, presentaría el informe en el que se detalla la postura de seguridad de lo que ha creado tanto para el cliente como para crearlo de tal manera (PDF, etc.) que pueda presentarse al proveedor.

Uno de los problemas fundamentales con PHP es realmente un problema fundamental con el modelo CGI de las cosas (en el que se basa PHP, a pesar de las trampas de mod_php ), es decir, que los datos de cara al usuario están entremezclados con scripts, y se vuelve muy fácil por ejemplo El usuario carga para convertirse en un script ejecutable. Esto no es necesariamente un problema con PHP en sí mismo, pero tener PHP disponible en un sistema lo convierte en una gran superficie de ataque; Un buen número de problemas de seguridad de los complementos de WordPress provienen de este aspecto, por ejemplo.

Las implementaciones tradicionales basadas en CGI históricamente mitigaron este problema al permitir que los scripts CGI se ejecuten desde un directorio confiable (como /cgi-bin/ ) pero muchos proveedores de alojamiento compartido finalmente relajaron esta restricción por "conveniencia", y esa misma conveniencia es generalizado en PHP.

Muchas aplicaciones modernas basadas en PHP utilizan a menudo .htaccess como un mecanismo de enrutamiento de solicitudes rápido y sucio que ayuda a mitigar estos problemas, pero esto está lejos de ser universal y aún no es una cura fácil.

En mi opinión, el mayor problema con PHP es que es muy fácil que un código PHP arbitrario esté disponible para ejecutarse en cualquier servidor donde esté configurado, y por lo tanto, el código escrito en PHP no es necesariamente más o menos seguro El código escrito en otros idiomas (aunque su biblioteca estándar no es exactamente haga cualquier favor cuando se trata de escribir código seguro), el mecanismo por el cual se ejecutan los scripts PHP proporciona un enorme desafío de seguridad por el mérito de que PHP esté disponible en un servidor.

Estoy de acuerdo con su evaluación de que el uso de PHP no requiere un riesgo de seguridad. Hay algunos proveedores que se alejan de PHP por la misma razón por la que WordPress es visto como un riesgo de seguridad. Es popular Cuanto más prevalece algo, más energía se invierte en desarrollar exploits.

Dicho esto, no evitaría PHP si se implementa correctamente, recibe parches oportunos y tiene algún nivel de monitoreo para detectar actividad maliciosa. Conclusión: los riesgos de seguridad son riesgos de seguridad independientes de la plataforma. Cambiar los lenguajes de scripting no mitiga los riesgos de seguridad asociados con el código mal escrito / desarrollado / implementado.

Si lo único que desea es incluir un encabezado / pie de página estándar, PHP podría ser una exageración: las simples inclusiones del lado del servidor podrían hacer eso.

PHP no es intrínsecamente peligroso, como han argumentado las respuestas anteriores. Pero si no necesita un lenguaje de script completo en el servidor, la mejor práctica de seguridad es no instalar uno. Si, como usted dice, PHP se instalará en el servidor de todos modos, entonces el riesgo adicional creado al usarlo es de alrededor de cero siempre y cuando no haga nada estúpido. Y la inclusión de una plantilla no es estúpida a menos que se analice de alguna manera el nombre del archivo desde un parámetro de URL.

El formulario de contacto necesitará algún tipo de API y una base de datos detrás de él para manejar la solicitud POST cuando alguien la envíe y es la forma en que se escribe esta parte lo que hará o deshará las cosas, sea cual sea el idioma que use, si es un SQL La base de datos entonces la inyección SQL vale la pena buscarla; Si la entrada del usuario es devuelta de alguna manera a ellos o al cliente en una página web, entonces se debe considerar la inyección de script (java) y todo debe escaparse de HTML. En comparación con el formulario de contacto, usar una inclusión es lo más seguro posible.

Si solo quería un conjunto de páginas web, no una aplicación web interactiva, lo último en seguridad es usar un generador de sitio estático: el servidor solo tiene que servir archivos, lo que proporciona una superficie de ataque mucho más pequeña.

Entonces:

¿Qué tan cierta es la afirmación de que el uso de cualquier script PHP, no importa lo sencillo que sea, es un problema de seguridad inherente?

Expresado de esa manera, casi ninguno. Un script de inclusión de encabezado no es una vulnerabilidad. Tener PHP instalado en primer lugar cuando no lo necesita no es la mejor práctica de seguridad, tenerlo instalado y no actualizarlo regularmente siempre que aparezcan parches de seguridad es un problema potencial, ya que no tiene una política de quién es responsable de estas actualizaciones - Una vez que haya terminado el diseño del sitio, ¿estará el cliente a cargo de esto? O el proveedor de alojamiento? Si al cliente le preocupa eso, no deberían tener PHP en el servidor en primer lugar. Si no es así, entonces no hay ninguna razón relacionada con la seguridad para no usarla en lugares donde sabes lo que estás haciendo.

Los idiomas y las herramientas no son intrínsecamente inseguros, el código incorrecto y las prácticas de seguridad sí lo son.

Dado que php tiene una barrera de entrada baja, las personas que no entienden la seguridad de la red y la codificación segura pueden crear problemas de seguridad con las decisiones no informadas.

No es la herramienta, es el mono que la usa ;-)

El código escrito en cualquier idioma puede ser inseguro.

"Se muestran renuentes porque su compañía de alojamiento les advirtió que el uso de PHP es un problema de seguridad que podría permitir a alguien entrar en cPanel y obtener el control del sitio"

Si la empresa de hosting cree que necesita cPanel para ejecutar PHP, es hora de mover el host