¿Qué riesgos de seguridad existen al permitir que alguien cargue scripts PHP?

Es muy peligroso, porque está permitiendo que alguien cargue un archivo PHP con código desconocido e intenciones desconocidas, por lo que si necesita esta funcionalidad como parte de su sitio web, debería fortalecer su servidor, por ejemplo:

• Establezca un único directorio para cargar archivos PHP de los usuarios, debe aplicar los permisos de usuario correctos (lectura, escritura o ejecución) para este directorio, recuerde crear un usuario específico para este directorio, no use el usuario root.
• Puede crear un archivo .htaccess para el directorio, luego podría establecer configuraciones específicas para ese directorio ( Configurando el archivo .htaccess ).
• Valide el usuario de entrada, incluso usted debería establecer un formato de nombre específico y un tamaño máximo para los archivos PHP, si un archivo PHP no coincide con ese formato o si su tamaño es mayor que el permitido, la aplicación no debería permitir al usuario para subir ese archivo.
• Utilice la canonicalización antes de usar las funciones de archivo, por ejemplo: realpath , basename . Esto te ayuda a evitar el ataque de recorrido de ruta.

• Debería deshabilitar las funciones PHP con alto riesgo, por ejemplo: exec, shell_exec. Puede hacerlo a través del archivo php.ini; por ejemplo, podría agregar la siguiente línea para deshabilitar las funciones para la ejecución de comandos del sistema operativo y la administración de la configuración:

  disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
  

  La siguiente línea ayuda a desactivar las funciones para incluir o abrir archivos de fuentes externas:

  allow_url_fopen=Off
  allow_url_include=Off
  

Archivo de documentación oficial php.ini

Esas son algunas recomendaciones básicas. Debe analizar su aplicación web y sus necesidades para establecer la configuración correcta para su servidor y aplicación web.

Espero que esta información te ayude.

Si permite que alguien cargue y ejecute un script PHP en su servidor, efectivamente le otorga a esta persona el derecho de hacer lo que pueda hacer, si tuviera acceso ssh con nombre de usuario / contraseña para el proceso en el que se ejecuta el script PHP. .

Entonces, si la persona en cuestión ejecutara el script a través de Apache, la persona podría hacer cualquier cosa que el usuario de Apache en su servidor pudiera hacer.

Como un riesgo adicional, esta persona podría usar el acceso dado para intentar la escalada de privilegios, algo que probablemente rompería el acuerdo legal que tiene con ellos (usted tiene un acuerdo legal, ¿no es así?).

A mí me parece que estás a punto de dispararte en el pie. Permitir que personas en las que usted no confíe cargue y ejecute PHP en su servidor es extremadamente peligroso. Aquí hay algunas cosas que un atacante podría intentar:

• Ejecute comandos por lotes que se hagan cargo de su servidor web. Luego se puede usar como base de operaciones para atacar a otros servidores desde su red.
• Lee archivos que contienen secretos, por ejemplo, contraseñas, claves de cifrado, claves TLS, etc.
• Haga ataques XSS (usando JavaScript) para robar cookies de sesión u otras credenciales de sus usuarios. Esto es asumiendo que los archivos cargados se ejecutan en el mismo dominio o un subdominio que otras aplicaciones.

La lista sigue y sigue y sigue. Hay formas en que podría intentar bloquear estos ataques ( hmrojas.p tiene algunas sugerencias), pero eso no es sencillo. cosas que hacer. Las funciones de la lista negra son un comienzo, pero la lista negra nunca es más que una defensa parcial. Incluso para los mejores expertos, contener a alguien que puede ejecutar PHP es un desafío.

Al final, si no confía en la persona que escribió el código, deberá auditarlo cuidadosamente y manualmente para asegurarse de que sea benigno. Esto requiere tiempo y esfuerzo, y no es compatible con la carga directa de archivos.

A veces, el único movimiento ganador es no jugar. Yo diría que este es uno de estos casos.

Si bien hay sitios que le permiten ejecutar código PHP a pedido (es decir, 3v4l ), limitan severamente lo que puede hacer y salta a través de algunos aros importantes para hacerlo de manera segura

  

Utilizo una configuración donde los scripts se ejecutan en una pequeña máquina virtual. Por razones de seguridad, esta máquina no tiene red y solo un sistema de archivos mínimo. Los scripts son ejecutados por un demonio (escrito en Golang) y los resultados (con estadísticas) son reportados a una base de datos PostgreSQL. Todos los resultados se almacenan y se utilizan para proporcionar promedios para el resumen de rendimiento.

No permitiría a los usuarios cargar scripts PHP en un entorno en vivo. Una vez tuvimos un interno que estaba escribiendo un script de carga de imágenes. Excepto que se olvidó de validar algo sobre el archivo que estaba aceptando. Alguien subió un script de malware PHP desde Turquía e intentó tomarlo (él también se habría salido con la suya si no hubiera sido por otros esfuerzos de seguridad en el servidor).

PHP tiene muchas funciones para deshabilitar funciones y restringir ciertas acciones para que pueda usarse en escenarios de alojamiento compartido. Por lo tanto, es mucho más seguro permitir que las personas carguen scripts php que los scripts perl, cuando su servidor web y su instancia php están configurados correctamente.

Así que quiero abordar otra cosa que no sea la seguridad de urlopen y similar: Estás permitiendo que las personas ejecuten sitios interactivos.

Las consecuencias son peligrosas, independientemente de la cantidad de IO de la red o del disco que puedan generar, ya que, por ejemplo, pueden configurar un sitio de phishing, lo que puede afectar negativamente a su dominio y reputación de IP.

Por lo tanto, no terminas en una lista negra debido a los correos no deseados, ya que se bloquean al no permitir que php los envíe, pero posiblemente porque estás ejecutando un script que busca el inicio de sesión de Facebook del usuario.

Mencionas un servidor Apache, pero no si tiene PHP instalado o no.

Cualquiera de las partes del software se puede usar / instalar sin el otro.

Ambas piezas de software están disponibles para múltiples sistemas operativos ... no has mencionado cuál está en juego aquí.

En el caso de que PHP esté instalado en el servidor:

El riesgo es que, si la cuenta de usuario PHP termina ejecutándose, tiene derechos administrativos en la máquina, pueden hacer cualquier cosa en la biblioteca de PHP.

Si esa cuenta no tiene derechos administrativos, esto restringe lo que pueden hacer.

Algunos sistemas operativos tienen vulnerabilidades detectables / conocidas que permiten a las cuentas no administrativas 'obtener' derechos administrativos. Estos son conocidos como explotaciones de escalada de privilegios. Si se usa uno, entonces otra vez ... pueden hacer cualquier cosa en la biblioteca de PHP.

En el caso de que PHP no esté instalado en el servidor:

Hay poco o ningún riesgo en absoluto. Un archivo PHP es solo un archivo de texto de instrucciones que PHP interpreta y actúa. No es más dañino que un archivo de texto con una receta de guiso.

No hay manera de que puedas "asegurar" esto. Cualquier cantidad de permitir que alguien / cualquier persona ejecute código a voluntad en un sistema puede llevar a la toma de control completa del sistema, ya sea inherentemente a la ejecución de todas las instrucciones debido a defectos en el sistema que está tratando de evitar que se usen ciertas funciones.

Incluso un lenguaje de secuencias de comandos en una cárcel / chroot / contenedor como usuario dedicado puede, en última instancia, explotar vulnerabilidades (existentes / nuevas) que permiten un acceso completo a la raíz y más (es decir, acceso al firmware). Esto es con lo que los proveedores de alojamiento compartido tienen que lidiar todo el día. La mayor parte de la prevención y la reparación provienen de dos cosas:

1. Legal; haga una lista de lo que pueden y no pueden hacer en un contrato con anticipación

2. proceso; Disponer de redundancia y esquemas de recuperación para hacer frente a las infracciones / pérdidas

Sí, vas a querer sandbox esto. Probablemente, la forma más sencilla de hacerlo es con la ejecución en una VM o contenedor docker . Por supuesto, entonces necesitarás auditar la seguridad alrededor de eso.