Juan Cuartas es un miembro del grupo Hablemos de Laravel que hizo este interesante artículo de cómo evitar que se muestren las variables de entorno de nuestro proyecto Laravel y me lo acerco para que lo publique para todos ustedes. Si te gusta el artículo, no olvides dejarle un mensaje de agradecimiento a Juan por su aporte. Ahora sí, al tip!
Hace unos días asesorando un proyecto en Laravel 5.8, que ya se encuentra en producción, me encontré que este tenía el debug habilitado en el archivo .env APP_DEBUG=true
, el problema es que cuando se presenta este caso; toda la información que está en este archivo queda expuesta al usuario o cualquier persona que acceda al sitio tales como: DB_DATABASE
, DB_USERNAME
, DB_PASSWORD
entre otros 😰.
Y hay muchos laravelos que se olvidan de cambiar la variable APP_DEBUG
a false
. Lo pueden comprobar en Google:
Esta imagen de Google da bastante miedo no? Como te habrás dado cuenta, esto lleva a un riesgo muy grande en la seguridad ya que nos podrían llegar a hackear el sitio.
Otro ejemplo es que, al tener la variable en APP_DEBUG
en true
, el Whoops se muestra con todos los valores del archivo .env
.
Se puede observar que toda la información queda expuesta, hasta la estructura donde esté almacenado el proyecto, claro que hay muchas más variables que quedan expuestas.
Solución
Tenemos varias soluciones para evitar que esto suceda.
La primera y la más obvia es que debemos recordar siempre poner APP_DEBUG
en false
.
Pero si por algun motivo nos llegamos a olvidar de hacer este paso en el deploy, tenemos una herramienta que muchos desarrolladores lo han pasado por alto y se llama debug_blacklist.
Enmascarando las variables de entorno con Debug blacklist
Es un array el cual se conforma 3 Llaves
_ENV: las variables que se muestran en Enviroment Variables
_SERVER: las variables que se muestran en Server/Request Data
_POST: las variables que se envían por medio de este método
Vamos a hacer un ejemplo de cómo sería la configuración de dicho array en el archivo config/app.php. Se van a ocultar las variables: APP_KEY, DB_DATABASE, DB_USERNAME, DB_PASSWORD, tanto en la llave _ENV como en _SERVER.
Ahora comprobamos de nuevo en la página que muestra el error.
Podemos observar como los valores de estas variables ahora son reemplazados por ****, si fuera el caso de DB_PASSWORD este ejemplo está vacío entonces muestra “” pero como no está incluido en el array este quedaría expuesto
Otra solución
Otra solución es que le demos permisos 400 o 440 al archivo .env con CHMOD para que los usuarios públicos no puedan acceder a él.
Conclusión
Utilizar debug_blacklist
nos ayuda a proteger la información de las variables de entorno de los proyectos que se tienen en producción y de casualidad se dejó el APP_DEBUG
en true
, podemos agregar cualquiera de las variables que aparecen en la pantalla del error y estas serán ocultas como las mostradas anteriormente.
En la documentación de Laravel 5.7 empieza aparecer la información acerca de esta configuración, pero se realizaron las pruebas con un proyecto en la versión de Laravel 5.5 y funciona sin problemas.
No te olvides de agradecerle a Juan Cuartas por su interesante artículo y si tu también quieres escribir sobre un tema interesante y que se publique en Laravel Tip, entonces enviamelo a laraveltip@gmail.com.
Referencia: https://laravel.com/docs/5.7/configuration#hiding-environment-variables-from-debug
Más que oportuno, tu post. Gracias Matías!
Creo que la solución más efectiva es configurar bien el DocumentRoot del servidor web, hay que apuntarlo a la carpeta public (miproyecto/public) del proyecto y no a la raíz «miproyecto»
Si, ese también es una muy buena solución. Mas para los que tiene share hosting.
Es una buena solución, sin embargo si no haces la configuración de la que se habla en el tip, los datos quedan expuestos, porque ahí no se está exponiendo el archivo .env como tal si no los datos que este contiene
Si, pero la configuración la podes hacer al principio del proyecto y ya queda por si en el deploy te olvidas pasar a false la variable de entorno. Apunta a eso.
Así es, en varias oportunidades he visto que no hay ambiente de desarrollo y solucionan los errores en producción que es una mala práctica claro, pero no teniendo más recursos hacen el debug en producción y no la pasan a true
Ojo, si el DocumentRoot apunta a la raíz del proyecto y no a la carpeta public, al momento de escribir midominio.algo/.env de todas formas tendrán acceso al archivo de entorno, por eso es necesario configurar bien el servidor para evitar exponer el archivo y malos ratos.
Hay que tener presente, que si el server está mal configurado (ej. apuntando a la raíz del proyecto), todos los archivos de tu proyecto quedarán expuestos, incluyendo el .env sin importar el valor de APP_DEBUG.. en resumen, apunta tu DocumentRoot a la carpeta public y muestra al mundo sólo lo que debes mostrar..
Excelente trabajo, Saludos!!
Ni hablar! Gracias por la aclaración Vartob.
Para más seguridad claro que sí
Permisos 400 o 440 al archivo .env, VirtualHost DocumentRoot app plublic forder.
No es que el archivo .env quede expuesto, si no que en las páginas de error whoops queda mostrando toda la información, claro si el APP_DEBUG=true, claro que esa configuración que dices es excelente para cuando el archivo se puede acceder desde la url
Excelente post y de gran utilidad, muchas gracias
Muchas gracias por el post. A más seguridad mejor.
Excelente post , hay que recordar también de añadir el .env en el .gitignore para que no se suba al repositorio y queden expuestas credenciales importantes
Super interesante el tip y mas que estoy iniciando en este mundo de laravel/vue.
gracias Juan por compartir tu experiencia.
Excelente Tips. Gracias.
Pero si pongo el APP_DEBUG en false se resuelve todo? O sea que no tengo que enmascarar las variables de entorno.
Si y APP_ENV en
production
.Que genial post a tomarlo en cuenta!!!