¿El recorrido del directorio en una URL?

0

Escenario:

Tengo un servidor web que ejecuta nginx. Tengo mis archivos html en /var/www/ e imágenes en /var/www/pictures/ Sin embargo, también tengo algunas imágenes secretas en /var/www/pictures/secretpics/ que debo mantener ocultas.

Así que actualicé mi configuración de nginx con:

location /pictures/secrectpics/ {
   deny all;
   return 404;
}

Así que probé esto en mi navegador. Escribí www.myexamplesite.com/pictures/secretpics/secret01.png y recibí 404. (asumiendo que secret01.png es una imagen real).

Preguntas: 1. ¿Hay alguna forma de evitar esto y obtener acceso a secret01.png?

Por ejemplo, ¿es posible algo como lo siguiente? www.myexamplesite.com/pictures/../pictures/secretpics/secret01.png

  1. Si lo anterior es posible, ¿cómo debo asegurar mi secretpics ?
pregunta power 24.08.2017 - 07:28
fuente

2 respuestas

1

Dos pueden guardar un secreto si uno está muerto. Aseguras algo al no hacerlo disponible. En absoluto.

Obviamente, eso no es práctico. Así que piensa en todas las formas en que alguien puede obtener sus datos:

  • Configuración incorrecta del servidor que permite el acceso en línea. Los ataques transversales de directorio son un ejemplo de esto. Leer y comprender la documentación y aplicar actualizaciones de seguridad son buenas defensas contra esto.

  • Sólo adivinando. A todos les encanta odiar en la seguridad por oscuridad, pero a veces funciona bastante bien. Use un nombre largo con caracteres aleatorios (piense en "una buena contraseña"), no solo secret .

  • Rastreando los datos: utilice https !

  • Ataques MITM: respete los errores de certificado. Entrena a tus usuarios. Y espere lo mejor (no se detectará un ataque MITM realmente bueno; considere usar certificados de cliente también).

  • Ataque directo en el servidor: asegure los datos "en reposo" tanto como sea posible. Cualquier persona que tenga acceso físico a su servidor (en cualquier momento sin encriptación total del disco; o mientras el servidor se está ejecutando (por ejemplo, si sus datos están en un centro de datos o alojados por una empresa) puede verlos).

  • Atacar a los espectadores: asegure los datos en las computadoras remotas, no solo en el host web. Por ejemplo, ¿alguien puede acceder al caché de su navegador web en su computadora portátil después de ver los archivos?

  • Ataques internos: ¿puede confiar en todas las personas que están autorizadas para ver los datos? ¿Y si se lo envían a "un amigo?" ¿O re-publicarlo públicamente? ¿O enviarlo a un periódico oa la policía? Un buen consejo que he escuchado es que nunca ponga algo en línea que no le gustaría ver impreso en el periódico .

  • El hombre: ¿cómo se enfrentarán tus defensas contra una orden judicial? ¿Necesita preparar algunas protecciones extralegales, ejem ?

  • Chicos malos que toman un enfoque directo: ¿cómo resistirán sus defensas a criptoanálisis de manguera de goma ?

respondido por el drewbenn 24.08.2017 - 08:58
fuente
1

Según RFC 3986 Sección 5.4 , se ha especificado que se resuelva como absoluto de acuerdo con el URL en sí.

Puedes imaginar las ramificaciones de permitir que los puntos dobles no se marquen hasta que se usen para hacer referencia a un archivo de servidor real.

Hice una prueba con wget y la URL solicitada se convirtió en una URL absoluta.

Esto, obviamente, se basa en el código del cliente que solicita al recurso y al servidor que resuelvan las URL antes de que se usen dentro del servidor. El software del servidor, que en la mayoría de los casos sería Apache, NGINX, IIS o similar, nunca debe confiar en nada que provenga del cliente.

$ wget https://www.nytimes.com/section/world/../../section/politics
--2017-08-24 17:05:20--  https://www.nytimes.com/section/politics
Resolving www.nytimes.com... 151.101.29.164
Connecting to www.nytimes.com|151.101.29.164|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127149 (124K) [text/html]
Saving to: ‘politics’
    
respondido por el Nick Bedford 24.08.2017 - 09:07
fuente

Lea otras preguntas en las etiquetas