¿Usar una “contraseña” adicional en el Referer para ocultar el sitio privado?

37

Tengo un sitio privado (= soy el único usuario) en example.com/private/ . No se publica nada más en este host (es mi dominio).

No quiero que nadie sepa que hay algo en example.com , especialmente no mi sitio privado.

Ahora digamos que Alice "adivina" la URL y visita example.com/private/ . Por supuesto, he protegido el sitio al requerir un inicio de sesión, pero aún así, no quiero que Alice sepa que existe tal sitio, y no quiero que ella pruebe el inicio de sesión, etc.

Me pregunto si el siguiente método podría ayudarme aquí:

Con el complemento de Firefox RefControl puedo configurar una costumbre Referer encabezado para usar solo para solicitudes a un determinado host.

Establecí el Referer en (por ejemplo) 9b2389Bqa0-ub712/bauUU-UZsi12jkna10712 para cualquier solicitud en example.com .

Ahora verifico con .htaccess ( no sé cómo es posible exactamente, pero escuché que debería ser vea pregunta en Code Review SE ) para el Referente del visitante:

  • si es 9b2389Bqa0-ub712/bauUU-UZsi12jkna10712 , no haga nada especial (= el acceso al sitio es posible)
  • si es otra cosa, envíe el error HTTP 404

Supongo que en lugar de 404 se podría mostrar un sitio falso, pero para mi caso no quiero que nadie vea una diferencia entre /private (que existe) y /foobar (que no existe → 404).

¿Esto funcionaría? ¿Es posible con .htaccess ? ¿Tiene este método algún defecto? ¿Algo que deba cambiar? ¿Algún método similar?

Actualizaciones & aclaraciones

  • El host completo usa HTTPS.
  • No necesito ocultar el hecho de que hay un servidor, solo quiero ocultar que hay contenido servido.
  • Gracias @ Adnan por poner el término "negabilidad plausible" en juego → Quiero esto ( del lado del cliente)!

  • Algunos propusieron usar una URL difícil de adivinar (p. ej., la cadena secreta adjunta a la URL): si bien esto podría funcionar, creo que usar el método del Referer tiene la ventaja de que no puede revela accidentalmente el secreto (fácilmente). Las URL son más visibles que los encabezados HTTP: alguien que mira su pantalla, publica la lista de marcadores por accidente (sin recordar que se incluye la URL secreta), el historial del navegador, captura de pantalla de su escritorio con la barra de direcciones del navegador en el fondo, ... Y así tienes nuevamente el problema inicial: cómo ocultar que hay un sitio cuando Alicia "adivina" (o lo que sea) la URL.

  • Algunos propusieron usar una página de inicio de sesión externa (incluso mejor, local). Me gusta esa idea. En comparación con el método del Referer (si puede implementarse mediante .htaccess , que supongo que es posible) tiene la desventaja de que tal vez necesite adaptar el código / CMS del sitio.

  • Para una discusión sobre .htaccess , consulte la pregunta en Code Review SE

  • Como apunta @ НЛО, un encabezado personalizado sería mejor. Yo tambien pienso lo mismo. Pero no encontré un complemento de Firefox para eso todavía (consulte la pregunta sobre el superusuario ).

pregunta unor 08.04.2013 - 13:12
fuente

9 respuestas

44

Personalmentecreoqueloestáshaciendobien.Siemprequesumétododeiniciodesesiónsubyacenteseaseguro,agreguetantascapasdeoscuridadcomodesee.

Hetrabajadoconalgunosclientesquequeríanexactamenteloqueestástratandodelograr.Siempreheusadounodeestosdosmétodos:

  • Formulariodeiniciodesesiónentresitios:unarchivolocal.htmlquetieneunformulariodeiniciodesesiónenviadoalexample.com/private/login.php.Elformulariodeiniciodesesiónteníauncampohiddenconuntokengeneradoaleatoriamente.

Porsupuesto,cualquierapodríahaberdistribuidoelmismoarchivo.html,peroesonoeraimportante,porquenuestroprincipalmétododeseguridaderaelprocesodeiniciodesesión;elnombredeusuarioylacontraseña.

Serechazócualquiersolicitudaexample.com/privateysemostróun404alvisitante.PerocuandoserecibióunasolicitudPOSTconlascredencialescorrectas,seiniciaunasesiónenlaqueelsitiowebfuncionónormalmente.

Laventajadeestemétodoesqueleotorga deniability plausible . Si alguien se apodera del archivo .html , pueden intentar iniciar sesión y todavía obtendrán 404 . No hay pruebas de que este archivo esté relacionado con un sitio web que realmente funcione.

  • Contraseña adicional en la URL: es muy similar a su método, pero el token de autenticación adicional estaba en la URL. Se rechazó cualquier solicitud a example.com/private y se muestra un 404 al visitante. Pero cuando se recibe un example.com/private/login.php?token=Zz37vQQCnLTpe527xeFfFEG9 correcto, se ve el formulario de inicio de sesión.

A la mayoría de los clientes les gustó este método, ya que pudieron marcar esa URL. Sin embargo, la desventaja de este método es que NO le otorga una posibilidad de negación plausible. Cualquier persona con la URL puede probar que hay un formulario de inicio de sesión en funcionamiento en ese sitio web.

Para ser honesto, me gusta tu método y creo que podría usarlo algún día.

IMPORTANTE: Todo lo anterior se aplica solo después de , usted se asegura de que su método de inicio de sesión sea seguro.

    
respondido por el Adi 08.04.2013 - 14:17
fuente
15

Su método es funcionalmente equivalente a requerir autenticación con dos contraseñas, el Referer es una de ellas. Una variante más común es usar una URL secreta, es decir, para hacer que la "cadena especial" sea parte de la ruta al sitio privado. Incluir la cadena secreta en la URL puede incluir algunos detalles adicionales sobre los que pensar (por ejemplo, los usuarios pueden marcarla, lo que significa que la cadena está escrita en un archivo no tan oculto en la máquina del usuario), pero también aportar algunos detalles (por ejemplo, los usuarios pueden marque el marcador, haciéndolo compatible con todo tipo de navegador, no solo con Firefox-with-an-extension). Para facilidad de uso , tiendo a pensar que una cadena secreta en la propia URL es una mejor compensación, pero esa es tu decisión.

Espero que estés usando HTTPS para tu sitio completo. De hecho, si usa HTTP simple tanto para el público como para los sitios privados, entonces el pasivo de la escucha puede observar sus comunicaciones con el sitio privado, revelando sus contraseñas y todos sus secretos. Esto es malo.

Si usa HTTPS solo para el sitio privado, entonces tiene un servidor que escucha en el puerto 443, y los atacantes pueden verlo con bastante claridad (es tan simple como intentarlo con una conexión) ). Si el sitio principal y público es solo de HTTP, los atacantes pronto entenderán que hay un sitio privado (uno no se toma la molestia de comprar y configurar un certificado de servidor SSL solo por el gusto de hacerlo). Si desea que su sitio privado permanezca sin ser detectado, también debe usar HTTPS para el sitio público (algunas personas lo recomiendan genéricamente, por una variedad de razones, no todas ellas técnicas).

No sé el comportamiento exacto de la extensión RefControl, pero querrás asegurarte de que envía tu cadena especial Referer solo a la versión HTTPS de tu sitio, no el HTTP (si existe). De nuevo, personalmente me sentiría más seguro con una cadena secreta en la URL, porque al menos sé cuándo se enviará y cuándo no.

    
respondido por el Thomas Pornin 08.04.2013 - 17:40
fuente
6

Si no desea que alguien sepa que hay un servidor web en example.com a menos que se solicite alguna URL especial, entonces debe implementar esa regla como directamente en el nivel del cortafuegos de IP . Tiene que buscar los paquetes SYN que llegan al puerto 80 y mirar la carga útil para ver si es una solicitud HTTP válida para la URL permitida. Si no es así, simplemente suelte el paquete.

De lo contrario, si la solicitud de la URL incorrecta llega al servidor, el servidor anuncia su presencia al establecer la conexión TCP (y responder con un 404).

Si estás en Linux, puedes usar el módulo de cadena iptables para hacer este tipo de cosas.

Eche un vistazo aquí: enlace

    
respondido por el Kaz 09.04.2013 - 03:54
fuente
5

Sí, está bien. Siempre que la capa de contraseña sea segura, agregar más capas de oscuridad ayudará.

Algunos otros trucos (mezclar y combinar):

  • Solo se puede acceder a la página de inicio de sesión a través de una solicitud POST de AJAX (para iniciar sesión, crea una solicitud POST en la consola JS)
  • Haz que funcione solo si has accedido a example.com/trigger?pwd=abcd (que también es una página 404) en el último minuto.
  • Haga que la URL sea una función de la fecha y la hora. Algo fácil de calcular en una consola JS pero difícil de adivinar
respondido por el Manishearth 09.04.2013 - 09:44
fuente
2

Suponiendo que haya diseñado el sitio, lo mejor es agregar una cláusula al comienzo de la página "/ private /" se refiere a usted. La cláusula debería ser algo así como  if user.authenticated = true       Entonces "carga tu página"   Más        "Error 404"

Tenga en cuenta que mi etiquetado es muy general

La declaración de usuario autenticado podría cambiar con los idiomas de su página, pero simplemente comprobaría si Alicia ya había iniciado sesión, si no lo hubiera hecho obtendría el error 404, lo que significaría que tendría que ir manualmente a example.com/home.php o login.aspx o como se llame la página de inicio de sesión.

    
respondido por el chrisc 08.04.2013 - 13:52
fuente
2

Una solución: desactive la indexación de directorios y coloque su contenido en 'example.com/9b2389Bqa0-ub712-bauUU-UZsi12jkna10712'. Marcar esta URL especial. Un atacante que intente un ataque de enumeración de fuerza bruta obtendrá un error HTTP 404 genuino la mayor parte del tiempo. En su solución, los atacantes pueden realizar un análisis de tiempo y notar que los 404s desde '/ private' son más lentos que los de '/ nosuchpage'. En la solución que propongo, solo hay un tipo de respuesta 404.

Desventaja: URLs feas. Hay otras desventajas en las que puedo pensar, pero también están presentes en su esquema.

    
respondido por el Thomas Herlea 08.04.2013 - 16:00
fuente
1

Si el atacante obtuviera respuestas "HTTP 401 no autorizadas" sin importar a qué intentaron acceder, ¿eso contaría como el atacante descubriendo que hay "algo" en ese sitio? El atacante ya sabe que ese dominio está registrado y que hay un servidor web ejecutándose con ese nombre de host.

Si esta solución le conviene, use enlace

Desventaja: no puede reclamar "el sitio está vacío, verifique por sí mismo". Si necesitas eso, estás en un negocio interesante. :-)

    
respondido por el Thomas Herlea 08.04.2013 - 16:08
fuente
1

Puede usar este simple código PHP (crear un archivo index.php):

<?php
 if (isset($_GET['passkey']) && $_GET['passkey'] == '9b2389Bqa0-ub712/bauUU-UZsi12jkna10712') {
   ?>
   ... your html page ...
   <?php
 } else {
   header("HTTP/1.0 404 Not Found");
 }
?>

Si desea acceder a su sitio, simplemente abra la url 'www.example.com/?passkey=9b2389Bqa0-ub712/bauUU-UZsi12jkna10712'

    
respondido por el Nicola Pesavento 09.04.2013 - 00:19
fuente
1

En este caso, preferiría permitir que solo las solicitudes de Autenticación básica sean procesadas por un servidor web en esa URL. Entonces, si Alicia intentara adivinar, obtendría un 404 en example.com/private. Pero como sabe la URL, directamente puede enviar el encabezado de autenticación (es decir):

Autorización: QWxhZGRpbjpvcGVuIHNlc2FtZQ == básica

junto con su solicitud en example.com/private y que se aceptará y procesará

    
respondido por el gPlusHub.com 09.04.2013 - 11:50
fuente

Lea otras preguntas en las etiquetas