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

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.

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.

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

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

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.

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.

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. :-)

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'

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á