He oído decir que PHP es intrínsecamente inseguro. ¿Es esto cierto? ¿Por qué?
Según mi definición, es bastante difícil que un lenguaje sea "inherentemente inseguro", ya que un buen programador puede adaptarse. Pero PHP comenzó dejando muchos campos de minas por ahí para novatos.
Las versiones iniciales de PHP prestaron poca atención a la seguridad y el diseño tuvo algunas fallas grandes. Es difícil adaptar la seguridad en el software principal y en las bibliotecas. La capacitación en seguridad es difícil en las mejores circunstancias, y más aún cuando un subconjunto grande 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 se deshabilitó 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 función finalmente está programada para su eliminación completa en la próxima versión.
El lanzamiento temprano de PHP y la facilidad de implementación de aplicaciones PHP simples también atrajeron a muchos desarrolladores con poca conciencia de seguridad, y aseguraron un gran número de aplicaciones, un número significativo de los cuales tenía vulnerabilidades de forma remota. El tamaño y la vulnerabilidad de la base desplegada también atrajeron mucho interés por parte de la comunidad explotadora.
Aquí hay algunas referencias y enlaces útiles
Algunas de estas razones se describen en "Fractal de mal diseño ".
PHP es el ciego que guía a los ciegos. Leí el wikibook de PHP; debería llamarse "cómo escribir una aplicación absolutamente vulnerable". No puedo imaginar que se pueda publicar en cualquier otro idioma.
Relación con la seguridad. Si lees documentos de Python por cosas inseguras como serializar ( pickle ), verás una advertencia roja en la parte superior de la página "¡No usar en entradas no confiables!". ¿Qué hay de PHP?
Además del elemento anterior: en otros idiomas, el código se considera un problema si no entiende qué 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 reinicialización completa de un script en cada solicitud. Y eso provoca odio a los marcos: "¡Son lentos!". Pero los marcos eliminan las vulnerabilidades de inyección de código (inyecciones de SQL - al 100%). Hay una diferencia de principio: las declaraciones preparadas están 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 es incierto de manera predeterminada: tiene un defecto de seguridad a menos que lo arregle manualmente cada vez.
El intérprete de PHP en sí está roto. Los errores cero venenosos donde la API interpreta \ 0 como el terminador de la cadena, mientras que php no lo hace, ¿por qué Python no lo tiene?
La tipificación débil (es decir, la conversión automática silenciosa entre cadenas / números / et al.) es tan compleja que el menor esfuerzo de programador que se ahorra no vale la pena.
Hay al menos dos puntos para esto:
PHP es muy omnipresente, 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 adquiera un código inseguro si incluye bibliotecas de terceros en su aplicación.
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 scripts de Perl que utilizó, y creció a partir de ahí. Así que la seguridad no fue el aspecto más importante cuando la escribió, y muchas de las cosas que decidió usar en la versión de atrás que (porque era más fácil de programar) ahora son riesgos de seguridad.
El tema más popular es - más atención se 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 que funcionan bien, lo que conduce constantemente a fallas en las implementaciones de seguridad, versiones incompatibles. Como la mejor prueba, puede consultar MOPS . Realmente no creo que haya más para discutir.
No, no es cierto. Puede escribir código seguro en PHP perfectamente bien. Sin embargo, una gran cantidad de código escrito en PHP es inseguro, y la razón es simple: PHP tiene una barrera de entrada relativamente baja, lo que significa que muchas personas que saben poco sobre seguridad escriben en PHP. Por otro lado, PHP está orientado a la web, lo que significa que la aplicación pública de PHP puede ser atacada por cualquiera en Internet (mientras que, por ejemplo, la aplicación C ++ para el escritorio generalmente puede ser atacada solo por alguien que ya tiene acceso a dicho computadora de escritorio).
Los problemas principales son la configuración predeterminada y la barrera de entrada baja.
La forma más sencilla de implementar una aplicación PHP es instalar el horror ineficaz llamado "Apache" con mod_php , lanzar la aplicación mal desarrollada en /var/www y ver cómo se quema el mundo. 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á ahí para almacenar activos y contenido cargado por el usuario, y puede omitirse si la aplicación no lo necesita (si es solo una API REST, por ejemplo). Si un archivo .js se carga allí, no ocurrirá nada malo (puede causar daños en el lado del cliente como phishing o XSS, pero está fuera del alcance).
Por otro lado, utilizando nuestra configuración PHP predeterminada, 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 sitios de PHP en peligro provienen de formularios inseguros de carga de archivos.
Hay formas de hacerlo seguro, como separar la aplicación y el contenido: los archivos de la aplicación no deben ser accesibles a través de la raíz web, y ningún archivo debe ejecutarse desde el directorio de contenido. La mayoría de los marcos usan 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 archivo index.php que es el punto de entrada de la aplicación y se utiliza para arrancar 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 sirve todo lo demás como contenido. Incluso si se carga un archivo malicioso .php , solo se servirá como texto sin formato, para que todo el mundo se lastime los ojos ante el intento de un idiota por un compromiso con un sitio web.
Entonces, ¿por qué no todos hacen esto? Debido a " hola, ¿cómo instalo laravel framework en cpanel free hosting? Thx "
Por personas como esas. La barrera de entrada realmente baja significa que un poco de usuarios de PHP no son desarrolladores y no quieren convertirse en desarrolladores. Tenga en cuenta que no los considero desarrolladores porque copiar / pegar código de tutoriales sin entenderlo no significa serlo. un desarrollador, eso solo significa ser un idiota irresponsable: te conviertes en un desarrollador solo cuando puedes tomarte el tiempo de entender lo que estás haciendo y cómo puedes hacer las cosas de la manera correcta . Puede que esté 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 orientado a Internet. ;)
Dado que no pueden usar las pautas de seguridad ni los marcos de trabajo en el alojamiento compartido (y no se molesten en cambiarse a máquinas virtuales / servidores dedicados porque requiere una lectura que no quieren hacer porque el alojamiento compartido parece ser lo suficientemente bueno para a menudo, y el alojamiento compartido de PHP suele ser gratuito) siguen creando aplicaciones de mala calidad e inseguras y las implementan en servidores de alojamiento compartido de cPanel que ya están en peligro.
Hay muchos idiotas que pueden escribir código PHP ya que es un lenguaje muy simple.
Esto da como resultado una gran cantidad de código inseguro, especialmente los orificios de inclusión de código (estilo) include($_GET['page']) (remoto), orificios XSS y orificios de inyección SQL.
Python y Java no son tan populares para las personas que nunca han programado antes, por lo que hay menos novatos en la programación y, por lo tanto, la posibilidad de un código inseguro horrible es menor.
Otro aspecto: ¿Zend basaría su pila de PHP orientada a la empresa que es más vulnerable que la competencia? No es el lenguaje que se debe culpar por la inseguridad. Es el diseño. Un mal diseño puede ser implementado en todos los idiomas. La seguridad no es un estado, es un proceso. Y la base de contribuyentes masivos de PHP hace un trabajo bastante bueno.
El código se almacena en archivos de texto con formato de texto plano (.php). No está compilado ni encriptado, por lo que cualquier persona que comprometa su máquina obtiene su código fuente. Y si tienen el código fuente, también tienen los datos de inicio de sesión para la base de datos y pueden ejecutar consultas como colocar, eliminar, insertar o seleccionar. Incluso asp se compila antes de desplegarse. La mayoría de las personas que usan php son desarrolladores intermedios que saben muy poco acerca de la seguridad del servidor.
Luego está WordPress. La mayoría de los sitios php ejecutan WordPress. WordPress es uno de los favoritos para las personas sin habilidades de servidor o de programación. Eso significa que no saben cómo asegurarlo correctamente. Es tan ampliamente utilizado que cualquier vulnerabilidad que sea descubierta sea publicada y explotada. La mayoría de los desarrolladores no tienen idea de lo que realmente está haciendo el código en su sitio de WordPress. Una vez más, WordPress almacena los datos de inicio de sesión en la base de datos en el archivo wp-config.php de texto sin formato y tiene un proceso de instalación muy poco seguro. De manera predeterminada, el instalador se puede ejecutar sin una contraseña, siempre que wp-config.php esté configurado y la base de datos (sin ninguna tabla) esté configurada. Si no eres lo suficientemente rápido, alguien ejecutará el instalador por ti e instalará algunas herramientas de administración de archivos para leer más archivos en tu sistema. Luego está la enumeración de usuarios y varios otros problemas.
Muchas personas siguen usando php 5.x para sus proyectos. Algunas de esas versiones ya no reciben actualizaciones de seguridad.
La propia comunidad de PHP también es un peligro para sí misma. Hay tantos tutoriales que fomentan el uso de localhost en cadenas de conexión de base de datos. Ejecutar su base de datos en la misma máquina que su código web o una máquina web directa en general es una mala práctica. La máquina orientada a la web no debe tener la base de datos en ella.