Chrome, proxys y formularios inseguros

El título de esta entrada se parece «curiosamente» al título de una película de miedo… Y al principio eso es lo que es, ya que desde el lunes estoy recibiendo esta pantalla en mi chrome cada vez que meto una incidencia en mi redmine:

El caso es que luego le dabas al botón de enviarlo de todas formas y la cosa funcionaba normalmente… Eso si, era sumamente molesto y tenía clientes que accedían a poner sus incidencias y no era plan tener que explicarles a todos que no es que ahora fuésemos menos seguros que antes, sino que chrome había activado una funcionalidad nueva.

Esa funcionalidad, que estaba prevista para chrome 86, pero que se activó con chrome 87 hace que cuando los datos de un formulario se envíen a una página que no tiene https activado se de la advertencia de que cualquiera podría interceptar los datos… Me parece muy buena advertencia, pero ¡Espera! todo el tráfico de mis webs ya va por https, ¿cómo es que recibo esa advertencia?

Según la especificación de chrome esto solo debía pasar si el formulario llevaba a una página no segura, así que revisé las etiquetas form y vi que eran rutas relativas (y si es relativa dentro de una página https debería llevar a una página https), así que decidí revisar el camino completo usando el inspector de chrome donde, efectivamente, vi que la petición se realizaba a una página https pero descubrí que el campo Location que aparecía en los headers de la petición venía como http y no https, ¿cómo podía ser?

Pues resulta, después de mucho buscar, que la gestión del https la estaba haciendo mediante un proxy inverso en apache y, parece ser, que la directiva ProxyPassReverse modifica el host del Location, pero no el protocolo. Por suerte esto tiene fácil solución y basta con incluir esto en el VirtualHost:

RequestHeader set X-Forwarded-Proto "https"

Antes de hacerlo no os olvidéis de añadir el módulo:

sudo a2enmod headers

Con esto ya conseguiremos que el proxy no confunda a chrome y que desaparezca el molesto mensaje…

Protege tu .git

Hasta hace poco en mi empresa utilizábamos subversion como repositorio, no somos un equipo grande y las funcionalidades que nos ofrecía el repositorio eran suficiente para nuestros proyectos.
Recientemente, debido a que un cliente nos ha impuesto utilizar git como repositorio principal y dado que nuestra relación con ellos es muy importante, decidimos mover todos nuestros repositorios a git. Tampoco es que vayamos a utilizar extensivamente las ventajas que nos ofrece, pero si que nos obligaría a funcionar de manera más fluida con una herramienta que vamos a necesitar si-o-si.

El caso es que, en nuestra anterior configuración, utilizábamos subversion para mantener el código de producción de algunas webs y al modificar el repositorio hicimos lo propio con git, teniendo una «feliz transición». El problema vino en que, realmente, no eramos conscientes de las diferencias reales que tenían los dos repositorios y dentro de los directorios servidos junto a la web en cuestión se encontraba el directorio .git.

¿Qué significa esto? Pues ni más ni menos que todo el mundo mundial tiene acceso a tu repositorio local y puede, entre otras cosas, acceder a todo el código de lo que hay allí publicado… Y eso no puede ser. ¿Qué hacemos para evitarlo?

Hay varias formas de hacerlo, dependiendo de si tienes o no un .htaccess en tu web o no y de la configuración de tu servidor, en mi caso la solución que implementamos fue añadir las siguientes líneas al archivo de configuración de cada web:

        <Directory /directorio.de.la.web/.git>
		Options FollowSymLinks
		AllowOverride All
		Require all denied
	</Directory>

Esto indica al servidor que todo lo que hay bajo el directorio .git no está autorizado para ser visto… Reiniciamos el servidor o recargamos la configuración y ya tendremos el problema resuelto.

Y con esto y un bizcocho… Podemos empezar nuestra semana.