Descargar un archivo de un servidor con un secreto: ¿en texto o binario?

Realmente no hay una diferencia.

Si utilizas el cifrado TLS adecuado, ninguno de los dos puede leerlo un intermediario, y si el servidor autentica correctamente las solicitudes, nadie que no esté autorizado podrá descargar el archivo.

Si no usa el TLS adecuado o no autentica correctamente a los usuarios, un atacante podría leer el archivo en ambos casos.

Definitivamente no deberías usar archivos comprimidos no protegidos por contraseña como medida de seguridad.

No ,

Si se especifica el tipo de archivo, entonces no hay ninguna seguridad adicional. Por ejemplo, descomprimir un archivo es tan trivial que no agrega ninguna seguridad.

Si pregunta si es más seguro compartir un secreto a través de un archivo con un tipo desconocido, esto es solo seguridad por oscuridad . La seguridad segura por la oscuridad desalienta a algunas personas, pero todavía no es seguro.

El formato del archivo es irrelevante para la seguridad del transporte de datos. Puede enviar de forma segura tanto texto sin formato como formatos binarios arbitrarios a través de un túnel TLS cifrado. Sin seguridad de transporte, los datos se pueden capturar de cualquier manera y solo se protegerían mediante cifrado en el formato mismo.

Con respecto a la seguridad en la capa de aplicación, la compresión de datos confidenciales ha sido históricamente una medida popular contra una clase de ataques de aplicaciones web relacionados con la detección de contenido. Por ejemplo, dependiendo del formato de los datos secretos y la previsibilidad de la ruta de descarga, puede introducir un inclusión de secuencia de comandos entre sitios (XSSI, no XSS) vulnerabilidad al ofrecer descargas de texto sin formato sin las medidas de seguridad adecuadas. Aquí hay un escenario imaginario para explicar el ataque:

Supongamos que cualquier usuario autenticado en su plataforma puede descargar un archivo de configuración confidencial específico del usuario desde esta URL:

https://yourservice.example/download/myconfig

El archivo de configuración tiene el siguiente formato:

user_id = 314159
secret_token = "719fe66f5159f86e798eabf930b8c9c2"

Ahora un atacante podría simplemente enviarle un enlace a un sitio web preparado con el siguiente contenido:

<script src="https://magicservice.example/download/myconfig"></script>
<script>
    alert(secret_token);
</script>

Lo que sucede aquí es que su navegador interpreta la respuesta del enlace de descarga como un código JS externo y, por lo tanto, pierde los valores de user_id y secret_token a la página controlada por el atacante como variables globales de JS. La compresión o el cambio de formato de los datos de alguna manera habrían evitado este ataque porque un archivo ZIP no puede producir un código JS válido. Si bien este caso específico puede parecer inverosímil, ha habido muchas otras vulnerabilidades relacionadas con el rastreo en el pasado.

Tenga en cuenta que la forma correcta y moderna de mitigar este escenario XSSI no es comprimir el archivo, sino enviar un encabezado X-Content-Type-Options: nosniff que obliga a los navegadores a aceptar solo JS con el tipo MIME correcto, y enviar un encabezado Content-Disposition: attachment que instruya a los navegadores para no mostrar la descarga en línea.

No importa si es sobre HTTPS. Puede leer un archivo binario tan fácil como un archivo de texto.

Sí, pero no lo suficiente como para que valga la pena preocuparse, excepto en las configuraciones más conscientes de la seguridad.

El texto es grande, voluminoso, y consiste en un conjunto de caracteres limitado conocido en general, mientras que un formato binario comprimido como zip es compacto y trata de usar el rango completo de valores posibles para sus bytes para necesitar el número más pequeño posible de bytes para representar el contenido. En general, también eliminará al menos los patrones cíclicos más significativos.

Todo esto hace que resulte más difícil descifrar el cifrado de la capa de transporte que está utilizando para asegurar la descarga. (De ahí que los programas como GPG comprimen los mensajes por defecto antes de encriptarlos). Pero luego, si configuró correctamente su TLS, el craqueo ya debería ser tan difícil que no tiene que preocuparse por nadie más que por los principales gobiernos. , e incluso ellos tendrían un tiempo lo suficientemente duro como para que simplemente se presenten en tu casa y te golpeen hasta que les des el archivo.

Si no está usando TLS, entonces no hay ninguna diferencia a menos que logre elegir un formato binario tan extraño que el adversario no pueda identificarlo ... En cuyo caso, su usuario probablemente tampoco podrá hacerlo. ... Entonces, también puede darles len ($ FILE) bytes de / dev / urandom para descargar y luego grabar el archivo real en el disco y enviarlo a la publicación.

Esto realmente depende un poco. Obviamente, como todos señalaron que la codificación como tal no evita ningún desafío adicional para un atacante, pero hay algo más que considerar.

Hay un par de cosas que normalmente no puede proteger al transferir datos cifrados, el origen y el destino es uno, la longitud es otra. Resulta que la longitud es un canal lateral sorprendentemente poderoso, echa un vistazo a enlace para ver un ejemplo de análisis de tráfico de Google Maps. .

El punto que estoy tratando de hacer es que en algunos casos raros la codificación puede afectar la seguridad de todo el sistema. Este es especialmente el caso cuando hay un pequeño número de estados de transmisión aceptables. Si solo puede elegir entre "No, no quiero la oferta de trabajo". y "Sí, envíe los contratos junto. (contrato adjunto)", entonces necesitará un relleno para que la respuesta no responda para que la información se vea igual.

Esta es solo una versión específica de la baja entropía en el problema de datos que a veces se ve en el hashing de identificadores y similares. Si solo hay un par de millones de entradas aceptables, su hash será fácilmente invertible.