it-swarm-es.com

¿Por qué la gente dice que PHP es inherentemente inseguro?

He oído decir que PHP es inherentemente inseguro. ¿Es esto cierto? ¿Por qué?

18
Moshe

Según mi definición, es bastante difícil para un lenguaje ser "inherentemente inseguro", ya que un buen programador puede adaptarse. Pero PHP comenzó dejando muchos campos minados por ahí para principiantes.

Las versiones iniciales de PHP prestaron poca atención a la seguridad y el diseño tenía algunos defectos importantes. La seguridad es difícil de adaptar al software central y a las bibliotecas. La capacitación en seguridad es difícil en las mejores circunstancias , y más aún cuando un gran subconjunto de desarrolladores no tiene experiencia y comenzó con valores predeterminados incorrectos.

Por ejemplo, no fue hasta la versión 4.2.0 que register_globals estaba deshabilitado de forma predeterminada, por lo que los datos recibidos a través de la red ya no se insertaron directamente en el espacio de nombres global. Esta característica finalmente está programada para su eliminación completa en la próxima versión.

El lanzamiento anticipado de PHP y la facilidad de implementación de aplicaciones simples PHP) también atrajo a muchos desarrolladores con poca conciencia de seguridad y aseguró una gran cantidad de aplicaciones, una cantidad significativa algunos de los cuales tenían vulnerabilidades explotables de forma remota. El tamaño y la vulnerabilidad de la base desplegada también atrajo mucho interés de la comunidad de exploits.

Aquí hay algunas referencias y enlaces útiles.

27
nealmcb

Algunas de estas razones se describen en "Fractal de mal diseño" .

  • PHP es el ciego guiando al ciego. Leí el PHP wikibook; debería llamarse "cómo escribir una aplicación absolutamente vulnerable". No puedo imaginar que pueda publicarse en ningún otro idioma.

  • Relación con la seguridad. Si lees los documentos python para cosas inseguras como la serialización ( pickle ), verás una advertencia roja en la parte superior de la página "No utilizar en aplicaciones no confiables input! ". ¿Qué tal PHP?

  • Además del elemento anterior: en otros idiomas, el código se considera un problema si no comprende lo que hace y cómo funciona. En PHP, el código se considera un problema si hay vulnerabilidades en la naturaleza.

  • PHP se ejecuta solo como CGI, lo que significa la reinicialización completa de un script en cada solicitud. Y eso causa odio a los marcos: "¡Son lentos!". Pero los marcos eliminan las vulnerabilidades de inyección de código (inyecciones SQL - al 100%). Hay una diferencia de principios: las declaraciones preparadas son seguras por defecto. No tiene que hacer nada para protegerse de las inyecciones de SQL, eso significa que no puede olvidarlo o no saberlo. No usarlos no es seguro de forma predeterminada: tiene un defecto de seguridad a menos que lo corrija manualmente cada vez.

  • El intérprete PHP en sí está roto. Ese venenoso cero errores donde la API interpreta\0 como el terminador de cadena mientras que php no lo hace, ¿por qué no python lo tiene ??

La escritura débil (es decir, la conversión automática silenciosa entre cadenas/números/et al) es tan compleja que cualquier esfuerzo menor del programador que se guarde no vale la pena.

  • Mira esto . ¿Crees que estás comparando 2 variables como cadenas? ¡Vaya, no lo eres! Aún más divertido , mi favorito. No todos los que pueden escribir un motor de foro en PHP pueden comparar 2 cadenas correctamente).
11
Smit Johnth

Hay al menos dos puntos para esto:

  1. PHP es muy ubicuo, y esto lo convierte en un objetivo interesante para los hackers. También significa que muchos programadores novatos usan PHP, porque es fácil de usar. Por lo tanto, es más probable que recoja código inseguro si incluye bibliotecas de terceros en su aplicación.

  2. Y supongo que el punto más importante es que PHP no fue diseñado para usarse en la escala que es hoy. Rasmus Lerdorf escribió PHP para reemplazar algunos Perl -scripts que utilizó, y creció a partir de ahí. Por lo tanto, la seguridad no era el aspecto más importante cuando lo escribió, y muchas de las cosas que decidió usar antes que (porque era más fácil de programar) ahora son riesgos de seguridad .

7
Andreas Arnold

El tema más popular es: más atención deriva. Esta es la primera verdad. La segunda verdad es que PHP desde el principio no estaba muy bien diseñado y hoy en día tiene muchos hacks internos para funcionar bien, lo que constantemente lleva a fallas en las implementaciones de seguridad, incompatibilidades de versiones. Como el mejor prueba de que puede verificar TRAPEADORES . Realmente no creo que haya más para discutir.

4
anonymous

Los principales problemas son la configuración predeterminada y la baja barrera de entrada.

La forma más fácil de implementar una aplicación PHP es instalar el horror ineficaz llamado "Apache" con mod_php, lanza la aplicación poco desarrollada en /var/www y mira el mundo arder. Eso funcionará, pero es un desastre de seguridad.

Por ejemplo, una aplicación Node.js se ejecuta como su propio proceso, en su propio directorio totalmente independiente de la raíz web. La raíz web solo está allí para almacenar activos y contenido subido por el usuario, y se puede omitir si la aplicación no lo necesita (si es solo un REST API, por ejemplo). Si a. El archivo js se carga allí, no sucederá nada malo (puede causar daños en el lado del cliente como phishing o XSS, pero eso está fuera del alcance).

Por otro lado, usando nuestra configuración predeterminada PHP configuración, si un archivo .php se carga y solicita, se ejecuta bajo los privilegios de la aplicación legítima, puede acceder y modificar sus archivos, acceder y extraer datos confidenciales de la base de datos, etc. Eso es un desastre, y la mayoría de los compromisos de PHP sitios provienen de formas inseguras de carga de archivos.

Hay formas de hacerlo seguro, como separar la aplicación y el contenido: los archivos de la aplicación no deberían ser accesibles a través de la raíz web, y ningún archivo debería ejecutarse desde el directorio de contenido. La mayoría de los marcos utilizan ese enfoque, donde todos sus controladores, modelos y vistas residen en el directorio app, y un segundo directorio public contiene todos los activos, contenido cargado y un solo index.php archivo que es el punto de entrada de la aplicación y se usa para bootstrap el marco y la aplicación. Luego configura el servidor web para usar el directorio public como raíz web , y solo ejecuta index.php mientras se sirve todo lo demás como contenido. Incluso si un malicioso .php el archivo se carga, solo se servirá como texto sin formato, para que todo el mundo se lastime los ojos frente al intento de un idiota de comprometer un sitio web.

Entonces, ¿por qué no todos hacen esto? Debido a " hola, ¿cómo instalo laravel framework en cpanel hosting gratuito? Thx "

Por personas como esas. La barrera de entrada realmente baja significa bastante PHP no son desarrolladores y no quieren convertirse en desarrolladores; tenga en cuenta que no los considero desarrolladores porque copie/pegue código de tutoriales sin entender que no significa ser un desarrollador, eso solo significa ser un idiota irresponsable: se convierte en desarrollador solo cuando puede tomarse el tiempo para comprender lo que está haciendo y cómo puede hacer las cosas de la manera correcta . Puedo estar sesgado, pero eso también significa ir a Stack Exchange y leer algunas cosas básicas sobre la seguridad del servidor antes de configurar un servidor web con conexión a Internet.;)

Dado que no pueden usar aplicar pautas de seguridad ni usar marcos en el alojamiento compartido (y no se molestan en cambiar a máquinas virtuales/servidores dedicados porque requiere algo de lectura que no quieren hacer porque el alojamiento compartido les parece lo suficientemente bueno, y PHP el alojamiento compartido a menudo es gratuito) continúan creando aplicaciones deficientes e inseguras y las implementan en servidores de alojamiento compartidos impulsados ​​por cPanel que ya están comprometidos.

2
user42178

No, no es verdad. Puede escribir código seguro en PHP perfectamente bien. Sin embargo, una gran cantidad de código escrito en PHP es inseguro, y el motivo es simple: PHP tiene una barrera de entrada relativamente baja, lo que significa un Mucha gente que sabe poco sobre seguridad escribe en PHP. Por otro lado, PHP está orientado a la web, lo que significa que la aplicación pública PHP puede ser atacada por cualquier persona en Internet (mientras que, por ejemplo, la aplicación C++ para el escritorio generalmente puede ser atacado solo por alguien que ya tenga acceso a dicha computadora de escritorio).

2
StasM

Hay muchos idiotas que pueden escribir el código PHP porque es un lenguaje muy simple. Esto resulta en un montón de código inseguro, especialmente include($_GET['page'])- style (remoto) agujeros de inclusión de código, agujeros XSS y agujeros de inyección SQL.

Python y Java no son tan populares para las personas que nunca programaron antes, por lo que hay menos novatos en programación y, por lo tanto, la posibilidad de un código inseguro horrible es menor.

1
ThiefMaster

Otro aspecto: ¿Zend basaría su empresa dirigida PHP stack que es más vulnerable que la competencia? No es el lenguaje al que se debe culpar por la inseguridad. Es el diseño. El mal diseño puede implementarse en todos los idiomas. La seguridad no es un estado, es un proceso. Y la base masiva de contribuyentes de PHP hace un trabajo bastante bueno.

0
djozsef