Ciberseguridad · PHP & Laravel

lo practico Laravel seguridad lista de verificación

Por · Última actualización: · lectura gratuita, sin muro de pago

La mayoría de las aplicaciones Laravel no son pirateadas por días cero inteligentes. Son pirateados por archivos .env expuestos, modo de depuración activado, PHP sin parches y SSH débil. Esta lista de verificación cubre primero el trabajo aburrido y de alto impacto (servidor, aplicación, dependencias, secretos y respuesta) con una forma de automatizar cada paso.

En esta guía
  1. ¿Qué es lo que realmente hace que se pirateen Laravel aplicaciones?
  2. Lista de verificación de protección del servidor
  3. Lista de verificación de endurecimiento de aplicaciones
  4. Dependencias y cadena de suministro
  5. Secretos y protección de datos
  6. Detección, seguimiento y respuesta
  7. Preguntas frecuentes

¿Qué es lo que realmente hace que se pirateen Laravel aplicaciones?

Clasificados por la frecuencia con la que aparecen en incidentes reales, no por lo interesantes que son:

  1. Salida de depuración expuesta. APP_DEBUG=true en el entorno de fugas de producción variables, credenciales de bases de datos y rutas de archivos a cualquiera que provoque un error.
  2. Legible .env o .git/. Raíces de documentos mal configuradas que servir archivos de puntos, entregar su APP_KEY y sus credenciales.
  3. PHP, marco o paquetes sin parches con CVE conocidos.
  4. SSH débil: autenticación de contraseña, inicio de sesión de root habilitado, sin protección de fuerza bruta.
  5. Cargas de archivos inseguras que permiten contenido ejecutable en rutas web.
  6. Inyección en las trampillas de evacuación: SQL sin formato sin enlaces, sin escape {!! !!} Salida de cuchilla.
  7. Paneles de administración sin MFA y sin limitación de tarifa.

Lo aburrido vence a lo inteligente: si cierras estas siete puertas, estarás por delante de la gran mayoría de la producción PHP implementaciones.

Lista de verificación de protección del servidor

Lista de verificación de endurecimiento de aplicaciones

Dependencias y cadena de suministro

Su aplicación es principalmente código de otras personas, así que trate la higiene de dependencias como un control de seguridad de primera clase:

Secretos y protección de datos

Detección, seguimiento y respuesta

Pon esto en práctica con Cipi

Cipi es la open-source implementación gratuita CLI a la que se hace referencia en esta guía: un comando se convierte en un nuevo Ubuntu VPS en un servidor de producción reforzado para Laravel — Nginx, PHP-FPM o Octane, MariaDB o PostgreSQL, colas, programador, SSL e implementaciones de Git sin tiempo de inactividad incluidas.

wget -O - https://cipi.sh/setup.sh | fiesta

Preguntas frecuentes

¿Laravel es seguro de forma predeterminada?

El marco incluye valores predeterminados sólidos: protección CSRF, contraseñas hash, protección de inyección SQL a través del generador de consultas y salida Blade de escape. La mayoría de los incidentes del mundo real provienen de errores de implementación (modo de depuración activado, archivos .env expuestos, PHP sin parches, SSH débil), razón por la cual el fortalecimiento del servidor es tan importante como el código de la aplicación.

¿Cuál es la configuración de seguridad Laravel más importante?

APP_DEBUG=false en producción. Una página de depuración expuesta filtra variables de entorno, credenciales y rutas, y sigue siendo la infracción Laravel autoinfligida más común. Verifíquelo ahora y luego automatice la verificación en su proceso de implementación.

¿Con qué frecuencia debo actualizar PHP y mis dependencias?

Aplique parches de seguridad tan pronto como sea posible: automatice la detección con la auditoría composer en CI y Renovate o Dependabot para actualizar las relaciones públicas. Para el propio PHP, utilice un mecanismo administrado en lugar de memoria: Cipi, por ejemplo, realiza comprobaciones semanales y aplica PHP parches de seguridad mediante la actualización cipi php.

¿Necesito un WAF para una aplicación Laravel?

Un WAF es una capa adicional útil, no un sustituto de lo básico. Primero cierre los fundamentos: TLS, software parcheado, SSH reforzado, entrada validada, limitación de velocidad. Después de eso, un WAF a nivel de CDN agrega una defensa en profundidad contra ataques automatizados.

¿Qué debo hacer primero si sospecho que hay un servidor comprometido?

Aislar la máquina del tráfico, rotar todos los secretos que contiene (contraseñas de bases de datos, tokens API, APP_KEY), restaurar la aplicación en un servidor limpio a partir de una copia de seguridad en buen estado y solo entonces investigar el punto de entrada. Parchar el host comprometido en vivo y esperar es la forma en que los atacantes mantienen su posición.

Sigue leyendo