security - reputation - virustotal apk

¿Las URL secretas son verdaderamente seguras? (8)

¿sería eso de alguna manera descubierto por un tercero sin obtener la información de mí? Por ejemplo, los puertos secretos pueden escanearse y tomarse las huellas digitales, pero ¿se puede hacer el mismo tipo de táctica para las URL secretas?

Sí. Estás pensando en la amenaza como un ser humano sentado en una computadora escribiendo la URL en su navegador. La realidad es que los atacantes usan programas automáticos que realizan reconocimientos en los sistemas y usan esa información para intentar una variedad de ataques. Probar URL aleatorias tiene un costo bajo para un sistema automatizado que puede generar cientos de solicitudes HTTP por segundo. Segundo, como han notado otros, una vez que usas la URL ya no es un secreto. Esos programas automatizados escuchan el tráfico de Internet y recopilan URL para intentar ataques. El hecho de que solo usted conozca la URL significa que ninguna otra persona puede divulgar su valor. No evita que los medios técnicos divulguen el valor.

Nunca dejo puertas traseras en mi sistema, pero por curiosidad me preguntaba si dejé una URL secreta como / x52d23r que permitiera pasar por alto algún tipo de seguridad, y esto era solo para mi uso personal --- ¿sería eso descubierto de alguna manera? un tercero sin obtener la información de mí?

Por ejemplo, los puertos secretos pueden escanearse y tomarse las huellas digitales, pero ¿se puede hacer el mismo tipo de táctica para las URL secretas?

El motivo por el cual usar una "URL secreta" suele ser inseguro no se debe a que se trate de "seguridad a través de la oscuridad". En la teoría de la información, una URL secreta no es diferente de una contraseña o clave privada. ¿Se considera que las contraseñas y las claves privadas son una práctica deficiente porque son "seguridad a través de la oscuridad"? No.

Entonces, ¿cuál es la diferencia entre una URL difícil de adivinar y una contraseña difícil de adivinar?

La diferencia está en la gran cantidad de lugares inseguros y formas en que las URL se almacenan, muestran y transmiten. Ejemplos:

En barras de direcciones del navegador web, historiales y cachés *
Encabezados de HTTP Referer enviados a otros sitios *
En los registros de acceso del servidor web *
En proxy y niveles de acceso de firewall de capa 7
En los volcados de paquetes
En los informes de tráfico de estadísticas web (por ejemplo, AWStats, Google Analytics) *

HTTPS puede proteger algunos de estos, pero no todos (los elementos marcados con un * no están protegidos contra el uso de HTTPS).

En un entorno altamente controlado, las URL difíciles de adivinar pueden ser seguras. Pero cuando se usan navegadores web comunes, servidores web y marcos web, no se debe confiar en las URL difíciles de adivinar a menos que no exista otra opción (e incluso entonces, debe considerar cuidadosamente).

El servidor web de Waterken es una plataforma web diseñada por el personal de seguridad en la investigación de HP sobre URL secretas (específicamente indescifrable criptográficamente).

Las aplicaciones creadas en él tienen algunas propiedades de seguridad muy interesantes como resultado.

Si se hace bien, las URL secretas criptográficamente fuertes pueden proporcionar altos niveles de seguridad.

ACLs Do not es un documento del equipo de Waterken en su arquitectura de seguridad.

Comparando la defensa sugerida con la solución basada en capacidad para el escenario de compilación, y asumiendo de nuevo un sistema tipo Unix: la URL es como el nombre del archivo; y el token indescifrable es como un descriptor de archivo, que se aproxima a la imposibilidad de forzarse de una capacidad con ingobernabilidad. Una página legítima del sitio web del corredor de bolsa abre por primera vez el recurso de compra de acciones, recibiendo un secreto indescifrable. El navegador utiliza este secreto indescifrable para escribir en el recurso de compra de acciones.

No es seguro.

Para el tráfico HTTP, su URL secreta sería efectivamente pública tan pronto como la use. Sin ninguna protección de contraseña, un intruso que escuche su tráfico de red podría ver la URL que envía y luego visitar la misma página.

No es una buena idea porque:

Alguien puede revelar que su url está ganando acceso local a su sistema / base de datos / aplicación
Algún día, algún administrador pondrá sus archivos de registro de acceso como públicos y google los encontrará.
Migrará / actualizará algo en la configuración de su servidor y se olvidará de proteger / ocultar esas URL

Yo diría que si tienes cuidado, pueden estar seguros. El mayor agujero de seguridad sería la gente que lo usa. Será compartido o publicado involuntariamente en algún lugar en el que Google lo indexará. Diseñe para eso, y úselo apropiadamente, como el método para compartir de Google Docs "Cualquiera con este enlace".

Usar HTTPS
Detiene la URL que se envía en texto sin formato
No establece los encabezados de referencia si hacen clic en un enlace HTTP
Si las personas acceden a su URL secreta a través de HTTP, avíseles y modifíquela inmediatamente
No se trata de seguridad a través de la oscuridad , es una mala interpretación del uso normal de la frase.
"Un sistema que confía en la seguridad a través de la oscuridad puede tener vulnerabilidades teóricas o reales de seguridad, pero sus propietarios o diseñadores creen que no se conocen los fallos y que es poco probable que los atacantes los encuentren".
En contraste, aquí estás siendo abierto con respecto a la implementación y el diseño.
No veo que esto sea menos seguro que la contraseña promedio cuando se usa con una URL larga y secreta (64 caracteres cualquiera? 2000 - longitud_del_dominio ?), En combinación con un asfalto.

Planeo usarlo en una aplicación donde siento que la gente valorará la simplicidad por encima de la seguridad.

esta es una idea bastante razonable si usa una url grande y generada aleatoriamente . hay muchos sistemas que realmente funcionan así. por ejemplo, en google docs, puede crear un enlace que cualquier persona con ese enlace puede editar el documento. Es lo suficientemente largo como para que nunca puedas adivinar ese vínculo. Además, los enlaces de restablecimiento de contraseña son básicamente esto, excepto que (afortunadamente) solo se pueden usar una vez. (vea abajo)

Deberás asegurarte de que el secreto no se haya filtrado. Eso significa usar https, no registrar accesos, o devolver el secreto en otras llamadas de API.

Dicho esto, como mencionan muchos de los comentaristas, una URL almacena todo tipo de lugares inseguros en su computadora, pero si un adversario tiene acceso a su computadora, ya está jodido. Es bastante típico suponer que su dispositivo de usuario final es seguro.

Además, cualquier secreto solo es secreto inversamente proporcional a la cantidad de gente que lo sabe. Puede ser tentador compartir una url con otras personas que requieren acceso. Un sistema mucho mejor podría ser hacer que cada URL funcione una sola vez, pero agregue una cookie al navegador del usuario, que es el token real. Básicamente, como un flujo de confirmación de contraseña / flujo de confirmación de correo electrónico, excepto sin contraseñas.

Respuesta original: la seguridad a través de la oscuridad es algo que nunca debería practicarse.

Me gustaría ampliar esto, ya que veo que aún se está discutiendo que una URL secreta no es diferente de una contraseña. Estoy muy en desacuerdo con esa comparación. Una URL secreta y una contraseña comparten una característica similar: son conocidas por una o más personas / personas específicas. Ahí es donde termina la similitud.

Fuerza de contraseñas

Hacer una contraseña de una serie de palabras al azar hace que la contraseña sea muy fuerte y muy difícil de adivinar o fuerza bruta .
Una contraseña debe combinarse con un nombre de usuario, que también puede aumentar la seguridad si el nombre de usuario no es común.
Las combinaciones de nombre de usuario y contraseña no se muestran estáticamente en la pantalla ni se almacenan en ningún lugar del navegador (a menos que elija que su navegador "guarde" sus credenciales de inicio de sesión).
Las contraseñas se pueden cambiar en caso de incumplimiento sin la necesidad de cambiar el punto de entrada en el sistema.
Los buenos sistemas de contraseñas no los almacenan en texto sin formato en el sistema de archivos.

Debilidad de URL secreta

A menos que se use en el modo "Incógnito", "Privado", etc., la URL se almacenará en su historial / caché local.
Las URL se muestran en la ventana del navegador y pueden tener acceso a ojos errantes.
Si la URL secreta está comprometida, debe cambiarla y notificar a cualquier persona que la use.
La URL existe en texto plano en el servidor en alguna parte, ya sea como directorio / archivos reales o como una reescritura (sin embargo, una reescritura podría estar bajada en un nivel mucho más alto).
Todo lo demás que @Mike Clark ha mencionado en su respuesta .

Lo que realmente se reduce a:

Las URL secretas solo practican la seguridad a través de la oscuridad. Eso es.
Las contraseñas pueden ser información oscurecida por definición, pero los esfuerzos adicionales, las precauciones y las protecciones que se toman alrededor de las contraseñas agregan un nivel de seguridad adicional a todo. En otras palabras, las contraseñas están en capas y están practicando la seguridad a través de otros medios, además de la oscuridad. Esto, a su vez, los convierte en una mejor opción que una simple URL oscurecida.

Recomendación: use una URL "secreta" y una combinación de nombre de usuario / contraseña muy sólida . No confíe solo en una URL "secreta".

Nunca practique la seguridad utilizando la oscuridad como única salvaguarda.