Estimado habrozhitel! Estimados expertos! Presento para su evaluación un nuevo concepto de identificación de usuario en sitios web, que espero que con su ayuda se convierta en un estándar abierto de Internet, haciendo que este mundo de Internet sea un poco mejor. Esta es una versión preliminar del protocolo de autenticación sin contraseña, diseñado como un artículo gratuito. Y si la idea subyacente recibe una evaluación positiva de usted, querido lector, continuaré publicándola en reddit.com y rfc-editor.org. Y espero poder interesar a los desarrolladores de los principales navegadores en su implementación. Por lo tanto, espero una crítica constructiva de su parte.

Atención: mucho texto.


Entonces la pregunta es. ¿Es posible identificar inequívocamente a los visitantes del sitio sin revelar sus datos personales y realizar un seguimiento entre diferentes sitios? ¿Es posible, al resolver este problema, abandonar por completo la forma más primitiva de autorización mediante inicio de sesión / contraseña y usar cookie / localStorage?

Por un lado, los sitios necesitan reconocer a un cliente para, por ejemplo, "restaurar" su configuración, cesta de productos, anuncios, artículos, etc. Por otro lado, los visitantes desean permanecer lo más anónimos posible, sin revelar sus datos personales y evitar que sitios de terceros los rastreen. Y este último puede hacer esto intercambiando entre ellos los datos recopilados.

Parece una tarea asegurarse de que los lobos estén llenos y que las ovejas estén a salvo. ¿Es esto real?

Yo, hasta cierto punto, creo, de verdad.

Tabla de contenidos

1 concepto de autenticación sin contraseña
1.1 Claves y tokens en lugar de inicios de sesión y contraseñas
1.2 Estructura del token
1.3 encabezados de protocolo HTTP
1.4 ¿Cómo identifican los clientes los sitios?
1.4.2 ¿Cómo sé si un sitio admite este protocolo?
1.5 ¿Cómo autorizan los clientes los sitios?
1.6 ¿Cómo implementar una identificación confiable del cliente?
1.7 Autorización en el sitio a través de los ojos del usuario
1.8 ¿Cómo cambia una clave de sitio?
1.9 ¿Cómo se implementa la autorización entre dominios?
1.10 ¿Cómo implementar la autenticación entre dominios?
1.11 Movilidad de cuenta

2 Descripción técnica del protocolo
Algoritmo de generación de clave de dominio 2.0
2.1 el algoritmo para calcular el token de origen
2.2 Algoritmo de protección de tokens durante la transferencia
2.3 Procedimiento de intercambio de sal entre navegador y servidor
2.4 Reglas para la formación del campo Contexto
2.5 Reglas para definir los campos Remitente y Destinatario
2.6 Detalles sobre tablas de definición de contexto
2.7 Escenarios de protocolo
2.8 Procesando tokens en el servidor
2.9 Autenticación entre dominios

3 Recomendaciones de seguridad
3.1 Protección de la información clave del acceso no autorizado
3.2 Acerca de las contraseñas como claves de dominio
3.3 Riesgos de perder / comprometer claves y minimizarlas

4 Ataques al esquema de autorización
4.1 Seguimiento de usuarios
4.2 ataque XSS
4.3 ataque CSRF
4.4 Seguimiento con SSO
4.5 Compromiso clave para SSO
4.6 Compromiso del token durante la transferencia
4.7 Hackear un sitio web y tokens comprometedores

Conclusión

1 concepto de autenticación sin contraseña

1.1 Claves y tokens en lugar de inicios de sesión y contraseñas

Para cada dominio, incluidos los secundarios, el navegador del cliente genera aleatoriamente una clave única de 256 bits $$ . Esta clave nunca se transmite. Permanece constante dentro de la sesión del usuario. Cada nueva sesión crea una nueva clave.
Clave basada $$ el navegador genera un token de 256 bits ^* usando un algoritmo especial $$ para identificar al usuario con un dominio específico. Token de identificación $$ el usuario (en lo sucesivo, simplemente denominado token) sirve como reemplazo de las cookies de sesión como PHPSESSIONID y JSESSIONID.
Clave $$ puede ser " arreglado " por el usuario. La fijación de la clave permitirá al usuario permanecer autorizado en el sitio por un tiempo ilimitado en diferentes sesiones del navegador y devolver la autorización existente anteriormente. Este es un análogo de la función "recordarme" .
Cuando se cancela la confirmación, el navegador "olvidará" esta clave y nuevamente comenzará a generar una clave aleatoria para este dominio para cada nueva sesión (comenzando desde la actual), que es análoga a la "salida" del sitio del usuario. La salida es instantánea, no requiere una recarga de página.
El usuario puede crear una clave permanente para el dominio . La clave permanente, así como la fija, permitirán al usuario devolver la autorización previa. De hecho, esta clave se convierte en un reemplazo para la conexión de inicio de sesión-contraseña.
El usuario tiene la oportunidad de controlar cuándo el navegador para el dominio usará una clave constante y cuándo, al azar. Este es un análogo de la función de inicio / cierre de sesión . El concepto se presenta en las capturas de pantalla a continuación .
Los métodos para generar claves de dominio persistentes proporcionan la movilidad de las cuentas de usuario entre diferentes dispositivos. El protocolo define lo siguiente:

• generación de una clave de dominio basada en una clave maestra de usuario
• formando individualmente una clave de dominio basada en un sensor biológico de números aleatorios
• Importar claves existentes desde un archivo de claves desde otro dispositivo

1.2 Estructura del token

El token es una estructura de 256 bits, representada como una cadena hexadecimal:

La parte de identificación del token (los 128 bits más altos) es similar al inicio de sesión. Mediante esta secuencia de bits, el servidor puede identificar de forma exclusiva al usuario.
La parte de autenticación del token (los 128 bits inferiores) es similar a la contraseña. Esta secuencia de bits ayuda al servidor a validar el token.
Las reglas de validación de tokens se describen a continuación .

1.3 encabezados de protocolo HTTP

Encabezados utilizados por el cliente:

CSI-Token : <Token> se usa para enviar un token al servidor
Ficha CSI : <Token1>; Changed-To <Token2> se usa para cambiar el token actual:

• al autorizar en una clave permanente,
• al registrar una clave permanente,
• al cambiar la clave permanente.

Token CSI : <Token> Permanente se utiliza cuando el usuario fija la clave aleatoria actual.
Token CSI : <Token> Cerrar sesión se utiliza para finalizar prematuramente la sesión actual.

Encabezados utilizados por el servidor:
Soporte CSI: sí le dice al cliente que el servidor admite el protocolo de autorización CSI.
CSI-Token-Action: el éxito se utiliza para notificar al navegador sobre la aceptación de un nuevo token de usuario (tecla Cambiar a).
CSI-Token-Action: abort cancela el procedimiento para cambiar los tokens (retroceder al token anterior).
CSI-Token-Action: el registro le dice al navegador que el nuevo token de usuario todavía está en proceso de registro.
CSI-Token-Action: error de verificación de token del lado del servidor no válido .

Finalmente
CSI-Salt es enviado tanto por el navegador como por el servidor al intercambiar la "sal" utilizada para proteger el token (parte de autenticación). Ver abajo para más detalles.

1.4 ¿Cómo identifican los clientes los sitios?

Un sitio puede usar un token para identificar a un visitante del sitio. Al mismo tiempo, el esquema de generación de tokens y su capacidad de 256 bits garantizan tokens únicos para cada par: dominio de usuario. Otro dominio verá otro token de usuario. Incluso si se ejecuta en el contexto del sitio de destino (a través de IFRAME, IMG, LINK, SCRIPT). Además, un algoritmo especial de generación de tokens protege a los usuarios de los ataques XSS, SRF y hace que sea imposible rastrear a un usuario sin su conocimiento. Pero al mismo tiempo, la tecnología SSO sigue siendo posible con su permiso e identificación entre dominios.
El token se transmite en el encabezado HTTP CSI-Token con cada solicitud a cualquier recurso de dominio (página, documento, imagen, script, estilo, fuente, archivo, solicitud ajax, ...):

El token se recalcula en cada solicitud HTTP (S) : página, imagen, solicitud ajax.
Para optimizar los cálculos, se permite el almacenamiento en caché de tokens por parte del navegador, pero solo durante la duración de la sesión y solo si las condiciones para cumplir con la solicitud permanecen sin cambios.
Como se señaló anteriormente, el token puede servir como un reemplazo para las cookies de sesión como PHPSESSIONID y JSESSIONID. La única diferencia es que si el sitio generó previamente un identificador para que el visitante rastree a un usuario específico entre sus diferentes solicitudes (después de todo, miles de solicitudes de diferentes usuarios llegan al sitio al mismo tiempo), ahora el cliente realiza esta función.
Dicha identificación es suficiente para permitirle realizar compras en la tienda en línea, anunciarse en sitios apropiados, escribir en foros, redes sociales, Wikipedia o Habré.
Sí, el usuario permanece anónimo para el sitio. Pero puede ser un anónimo "familiar" para el sitio. Y el servidor puede guardar el token de dicho usuario de su lado, junto con sus datos (cuenta personal con compras, preferencias, karma, bollos, me gusta y otras bonificaciones). Pero solo para mantener bajo la condición de completar cualquier proceso comercial: compra, presentación del anuncio, etc. Las condiciones están determinadas por el sitio en sí.
Como puede ver, el protocolo es lo más simple posible para los sitios que no necesitan registrarlo antes de darle la oportunidad de tomar cualquier medida. Pero aquellos que lo necesiten tendrán un poco más de dificultad. Pero más sobre eso a continuación.

1.4.2 , ?

http- CSI-Support: yes Response Headers :

, , . , :

, , www.youtube.com :

.

.

1.5 ?

, , – . , , – «».
, , , . .

: . . - .

« » . . « »:

, , . .
, , . .
, HTTP- CSI-Token-Action , . II .

1.6 ?

( , , ) , : , , . (, . , ).

1.7

, CSI, . , . :


, . :


, :


, -. . . , - / :


- «» :


. «» :

( ) HEAD, CSI-Token <>; Logout.

, , Logout. , ( ). , .
: , ajax-, .. – , .

: , , . «» . .

1.8 ?

, . II .
, , CSI-Token Changed-To :

. , , . . (Response Headers) : CSI-Token-Action: success , .
(, ) CSI-Token-Action: aborted.
, CSI-Token-Action, CSI-Token Changed-To.
« » .

1.9 - ?

La autorización clásica entre dominios utilizando la tecnología SSO tiene muchas ventajas para el usuario. No necesita recordar un montón de contraseñas de un montón de sitios. No es necesario registrarse y completar los formularios tristes. Algunos servidores de autorización preguntan qué derechos otorgar al sitio que solicitó el SSO.
Pero también hay desventajas. Depende del proveedor de SSO. Si el servidor SSO no funciona, no accederá al sitio de destino. Si pierde su contraseña o le roban su cuenta, pierde el acceso de todos los sitios a la vez.
Para los desarrolladores web, las cosas son un poco más complicadas. Desde el principio, debe registrar su sitio en el servidor de autorización, obtener las claves, aprender a trabajar con el protocolo ( SAML , OAuth , etc.) y las bibliotecas correspondientes, asegurarse de que la clave no caduque, que el servidor de autorización no bloquee su sitio por sus razones y etc. Esta es una tarifa por el hecho de que no necesita mantener cuentas de usuario, hacer formularios de registro, iniciar sesión, etc. La verdad aumenta el costo de mantenimiento (en forma de reparación de fallas repentinas). Nuevamente, si el servidor de repente no está disponible para el sitio, desafortunadamente.
Este esquema de autorización hace que SSO sea un poco más seguro, y la autorización para todos los participantes es más fácil. Sobre la seguridad se discutirá a continuación en la sección "Compromiso clave para SSO".

Eche un vistazo al sitio S, que admite el SSO de Google. Supongamos que tiene una cuenta de Google. Para iniciar sesión, haga clic en el enlace "Iniciar sesión con Google", que abrirá la pestaña de autorización de Google. El navegador le dirá que tiene una clave para Google. Y Google le dirá qué derechos solicita S.
Si está de acuerdo, haga clic en "Iniciar sesión" en el administrador de claves. La página se volverá a cargar. Google ya recibirá su token válido, lo reconocerá y lo autorizará. Y con una solicitud entre servidores, informará al Sitio S sobre la información de su cuenta de acuerdo con los campos solicitados.
La página recargada contendrá un botón "Siguiente" que lo regresará al sitio de destino.


El Sitio S puede decidir guardar datos sobre usted en su base de datos o no. Este problema está más allá del alcance del esquema de autorización propuesto. Pero además, donde consideraremos los riesgos de perder la clave para SSO, se recomienda que el sitio mantenga el token de usuario y el identificador de SSO a su lado, y se recomienda al usuario que cree una clave permanente para S.

Vulnerabilidad: después de dicha autorización, los sitios S1, S2, S3, ... (donde inició sesión a través de Google) podrán reconocerlo (por el identificador que le asignó Google) y, como resultado, realizar un seguimiento de su actividad.

Opción de protección: no trabaje simultáneamente en sitios si se registró a través del SSO del mismo proveedor. Si es posible, cierre sesión en el servidor de autorización inmediatamente después de que se complete la autorización ("salida automática" para el dominio).

1.10 ¿Cómo implementar la autenticación entre dominios?

Todo esto, por supuesto, es bueno. Si bien el trabajo se lleva a cabo en un navegador, todo está bien. Pero, ¿qué pasa con las realidades modernas cuando una persona tiene dos teléfonos móviles, una computadora que funciona y varios navegadores, una computadora doméstica y otra computadora portátil? Además de una tableta común para la esposa / hijos.
Tendremos que resolver de alguna manera el problema de transferir claves de dominio entre navegadores y dispositivos. Y también resuelva el problema de su correcta sincronización.
Uno de los mecanismos para resolver este problema es calcular varias claves de dominio basadas en una clave maestra común sin la posibilidad de recuperación inversa de la clave maestra a partir de una clave de dominio conocida.
Al crear una clave personal K para el dominio D utilizando la clave maestra M en un dispositivo, el usuario podrá crear la misma clave K para el dominio D y en cualquier otra utilizando la misma clave maestra M y un solo algoritmo. Más precisamente, esto no lo hará el usuario, sino su navegador. Con este enfoque, es suficiente que el usuario distribuya su clave maestra entre todos los navegadores utilizados por él y que "transfiera todas sus claves" de dominios a la vez. Al mismo tiempo realiza copias de seguridad de esta manera.
Máxima comodidad para el usuario. Pero también el riesgo máximo en caso de compromiso de la clave maestra. Por lo tanto, este último debe protegerse en consecuencia. Los riesgos de pérdida o compromiso de la clave maestra, y las formas de minimizar dichos riesgos se describen en el capítulo "3 Recomendaciones de seguridad" .
Usar solo una clave maestra para generar todas las claves para todos los dominios no siempre es una opción conveniente. En primer lugar, ¿qué hacer si de repente la clave de dominio se ve comprometida y necesita ser cambiada? En segundo lugar, ¿qué sucede si necesita compartir una clave de dominio con otra persona? Por ejemplo, entre miembros de la familia. ¿O es una cuenta corporativa de acceso al correo público? ¿Cómo "recoger" su clave (porque de hecho se ha visto comprometida)?
Por lo tanto, la generación de claves de dominio individuales utilizando un sensor biológico de números aleatorios debe ser compatible con los navegadores. Pero luego volvemos a la cuestión de nuestra movilidad y los problemas de sincronización, las funciones de exportación e importación de claves en el navegador y la creación de copias de seguridad.

Transferencia a través de un dispositivo físico enajenable

Las tarjetas inteligentes y los tokens usb pueden ser bastante adecuados como un almacenamiento seguro de información clave (porque fueron creados para esto). La autenticación de dos factores protege las claves del acceso no autorizado con acceso directo al dispositivo.
Es cierto que las tarjetas inteligentes requieren lectores especiales (sin mencionar los controladores), lo que limita su uso solo a estaciones de trabajo equipadas con dichos lectores.
Con tokens USB un poco más fácil. Solo se requieren conductores. Pero no puedes pegar tal token en el teléfono. Y aunque para los teléfonos móviles hay tokens hechos en forma de tarjetas SD, no quiere decir que esta solución aumente la movilidad. Intente sacar una tarjeta de un teléfono móvil, pero insértela en otra. Y no es que esto sea imposible. La cosa es que no es conveniente.
¿Y si se rompe la ficha? Entonces todas tus llaves irán al Gran Cthulhu.
Por lo tanto, habrá una tentación con este esquema para usar varios dispositivos duplicados. Pero aún debe resolver el problema de sincronización de claves si tiene varias tarjetas inteligentes.
Y, francamente, tales dispositivos no están protegidos de los keyloggers. Ahora, si el código pin se ingresara desde la tarjeta / token. Entonces otra cosa. Pero no he visto tal en la naturaleza.

Pros: se pueden usar claves aleatorias de 256 bits; alta seguridad mediante el uso de autenticación de dos factores; El más alto nivel de protección contra la manipulación directa.
Contras: dependencia del dispositivo; requiere costos financieros; baja movilidad; la necesidad de reservar tarjetas y, como resultado, sincronizar datos entre ellas; la vulnerabilidad a los keyloggers permanece.

Sincronización a través del servicio en línea

La "tecnología en la nube" ahora se utiliza siempre que sea posible. Parece que, junto con la cadena de bloques, se han convertido en un sustituto de la "tecnología bananera". Naturalmente, existe el deseo de utilizar una determinada plataforma de Internet para el intercambio de información clave. Una especie de tarjeta inteligente "en línea".
Que? Inicia sesión utilizando nuestro esquema de forma anónima en dicho sitio; envíe sus claves encriptadas con una contraseña allí; Pasas de otro dispositivo al mismo sitio con la misma clave / contraseña; obtienes las llaves desde allí; Sincroniza los cambios por la fecha de edición. Similar al administrador de contraseñas, solo esto está en línea.
Es solo que nadie garantiza que el servicio en línea no será pirateado o no combinará sus claves, aunque encriptadas, "cuando sea necesario". Quién implementará dicho servicio de forma gratuita. Eso es todo
Aunque, por supuesto, la contraseña protege las claves del uso directo. ¿Pero su contraseña es resistente a la fuerza bruta "fuera de línea"? Esa es otra pregunta.

Pros: alta movilidad de credenciales; independencia del dispositivo y del navegador; solo necesita una contraseña (aunque no dejaron la contraseña, ya es mejor).
Desventajas: menos seguro que almacenar claves en un medio alienable. De hecho, la seguridad de las claves se basa en la fuerza de la contraseña para la selección.

Por supuesto, puede usar una clave maestra para cifrar otras claves. Con la que se calculan otras claves de dominio. Como una opcion.

2 Descripción técnica del protocolo

Algoritmo de generación de clave de dominio 2.0

Este protocolo define solo 2 métodos para generar claves de dominio.

• basado en un generador de números aleatorios (preferiblemente biológico)
• basado en una clave maestra de 256 bits

En el último caso, la clave de dominio se calcula como:

$$

donde $$ - Clave maestra de 256 bits, Dominio: nombre de dominio para el que está hecha la clave.
De aquí en adelante, HMAC es un algoritmo criptográfico hash basado en una implementación de 256 bits de la función hash SHA-2 .

El compromiso o la divulgación voluntaria de una clave de dominio no compromete la clave maestra original.

La clave maestra proporciona un mecanismo para la movilidad de las credenciales de usuario.

Si la clave creada sobre la base del "maestro" se vio comprometida, o la ficha calculada a partir de dicha clave (como resultado de la piratería del sitio) se vio comprometida, entonces la clave debe cambiarse. Puede cambiarlo a una clave aleatoria de 256 bits, o generarlo desde el mismo "asistente", con la adición de una versión:

$$

De aquí en adelante, el símbolo $$ se usará para la operación de concatenación de cadenas (conjuntos de bytes).

2.1 el algoritmo para calcular el token de origen

El token de autenticación del usuario se calcula con cada solicitud de cualquier recurso de dominio. Para calcular el token de solicitud, se toman los siguientes datos:

• Remitente : el nombre de dominio del iniciador de la solicitud (puede ser una página con un iframe o un script del dominio de otra persona que realiza la búsqueda),
• Destinatario : nombre de dominio del destinatario (donde se envía la solicitud),
• Contexto : contexto de ejecución de solicitud,
• Protección : una secuencia aleatoria de 32 bytes (256 bits), si el Contexto está vacío; de lo contrario vacío

Estos datos se concatenan y se combinan con SHA-2 de 256 bits en la clave K del dominio que inicia la solicitud :

$$

Se obtiene un token válido cuando el Contexto no está vacío. Para una identificación adecuada en el sitio de destino, se debe cumplir la condición Remitente = Destinatario = Contexto.

El campo Contexto, junto con Protección, se usa para proteger contra ataques XSS y CSRF , así como contra el seguimiento de usuarios.
A continuación se darán explicaciones más detalladas sobre las reglas para determinar el Remitente / Destinatario / Contexto.

2.2 Algoritmo de protección de tokens durante la transferencia

El token original del cliente se transmite extremadamente raramente. Solo cuando se transfiere un token no registrado en el momento en que se creó la sesión.
Un token se considera no registrado si: se crea sobre la base de una clave aleatoria (no fija); no fue aceptado por el servidor después de enviar la clave Cambiar a o Permanente. Para obtener más detalles, consulte "Procesamiento de tokens en el servidor" .
El navegador y el servidor generan conjuntamente un par de números aleatorios, los llamados sal (Salt), con la que se dividen los 128 bits inferiores del token. Ambos intercambian estos números de acuerdo con el protocolo. Para obtener más información, consulte "Servidor-navegador de procedimientos de intercambio de sal" .
Por lo tanto, el servidor del sitio ve el siguiente token:

$$

donde $$ - alto 128 bits, $$ - los 128 bits inferiores del token original, $$ - Concatenación de cuerdas. En este caso, el token inicial $$ ya debería ser conocido por el servidor.

Idealmente, CSI-Salt debería cambiar cada vez que un navegador solicite un servidor. Sin embargo, esto puede ser un requisito costoso en términos de recursos informáticos. Además, puede "matar" la capacidad de enviar solicitudes paralelas al servidor.
Por lo tanto, para optimizar los cálculos, se permite mantener los valores de CSI-Salt sin cambios en diferentes solicitudes, pero no más de una sesión . Esto puede ser un límite de tiempo (cambio de CSI-Salt cada 5 minutos), o una reacción a la intensidad de las solicitudes (cambio de CSI-Salt cada 100 solicitudes), o después de cada serie de solicitudes (en el momento de la pausa, cliente-servidor), o una versión mixta. Aquí la decisión se deja a los desarrolladores del navegador.
Mantener CSI-Salt sin cambios durante demasiado tiempo debilita la protección del token transmitido, lo que permite al atacante interceptar el token mientras el usuario legítimo ha completado el cierre de sesión y ejecutar una solicitud no autorizada en nombre de la víctima.

2.3 Procedimiento de intercambio de sal entre navegador y servidor

2.3.1 Token basado en una clave de servidor aleatoria o no registrada ^[1] .

2.3.2 Token basado en la clave registrada por el servidor ^[1] .

---

^{[1] Un token se considera no registrado si: se crea sobre la base de una clave aleatoria; no fue aceptado por el servidor después de enviar la clave de cambio o permanente con CSI-Token-Action: respuesta de éxito.
[2] El tiempo a través del cual se realiza el cambio CSI-Salt lo determinan los propios navegadores. Esto puede suceder después de una serie de solicitudes, después de un tiempo de espera, después de un cierto número de solicitudes. – CSI-Salt .
[3] 16- 128- . , : _salt || S _salt . – , . , , .}

2.4 Context

, ( ). . .

, . , . , , ajax- .

, . , <script>, , . , <script>, , , . <script> .

LINK, SCRIPT, IMG, IFAME , - , DOM – .

FORM, A, META , (submit, click, timeout) – .

, . , .

FORM , , INPUT, .

, , , , , , . .

. , , click ( ), submit ( ) onclick/onsubmit.

. – META http-equiv=«refresh» content=«0».

^{P. Context}


( SRC IMG), , , / , — , «».

^{R. Context /}

---

^{[1]
[2]
[3] Inherit , Empty
[4] Inherit , Empty (. )}


P1..PF, R1..RC .

Referrer Domain . , , , .

2.5 Sender Recipient

Sender – //, . , , . ajax. . .

Recipient – , .

, .

site.net. :

• site.net/css/common.css
• common.css fonts.google.com/fonts/Roboto.css
• Roboto.css fonts.google.com/fonts/Roboto.ttf
• , img.site.net/picture1.jpg
• , adriver.ru/frame
• adm.site.net/admin.js

( adriver.ru) :

• adriver.ru/style.css
• img.adriver.ru/img/01.png
• adriver.ru/libs.js
• api.adriver.ru/v1/ad.js

Sender / Recipient DOM

Sender / Recipient ajax-.

Sender / Recipient

2.6 Context

, ( ) , Context .

P1 – submit . / . . .

site.net google.com, Context (google.com). site.net ( , ).

( ) P1 , Context site.net, .. Context = Referrer.

CSRF -.

P5 – , / , ; submit , / ( FORM, INPUT). / .

P9 – , P5 , , ( ).

PD – . .

URL . .

, , , , , PG ( ). F5, , PG . Enter PD .

CSRF- .

Context, , F5 ( ). , - ( P1 ).

, site.net, , . , , … , , , site.net.

P2 – , , click/submit. , . .

, Context . , Context .

P6 – , P2 , / / .

PA – , P2 , / / .

PE – window.location.href window.open(…).

site.net , Context . Context = site.net.

ya.ru, maps.ya.ru, Context . Context , .

, – . CSRF-.

P3 – P2 , click/submit . Context ( ), ( ).

P7 – P6 , / / .

PB – PA , / / .

PF – PE , .

P4 – <META>. . . Context . PE .

P8 — <META>. / . , Context . PE . .

PC – P8 , . Context .

PG – . , , . , , . , Context .

CSRF- .

, Context .

, , ( ) HTTP- Header. , Context . – .

- -.

, - . SSO- – .

« » , - . :

1. ;
2. SSO- , ;
3. SSO-;
4. SSO-, Changed-To, - ;
5. - «», ;
6. P1 , -, (, ).
7. -, , .

, , , . UI- :

SSO-. .

, , Context .

R1 – ( ). Context Context .

, site.net adriver.ru, img.disk.com, HTTP- img.disk.com Context , site.net.

R4 – , R1 . / , DOM Parser . , site.net/index.html site.net/require.js ( <script src=…>) site.net/min.js, main.js. Context , site.net.

R7 – , R1 . / , Context 256- . evil.com/drop.js, site.net, site.net , .. .

RA – . , site.net/css/common.css, site.net/index.html, fonts.google.com/fonts/Roboto.css, fonts.google.com Referrer = site.net/css/common.css. Context Referrer. Roboto.css Roboto.ttf, fonts.google.com/fonts/Roboto.ttf Referrer = fonts.google.com/fonts/Roboto.css. Context Referrer, .

, , Roboto.css ( ) /, CSRF- :

@import "https://site.net/api/payment?victim_params" 

con la esperanza de cumplir con la solicitud en site.net en nombre de un usuario autorizado. Pero el problema para el atacante es que site.net espera recibir un token del usuario:

$$

Luego, como con una solicitud CSRF, el navegador creará un token:

$$

Y una solicitud al sitio vendrá en nombre de un sitio anónimo que no tiene derechos de acceso para realizar estas operaciones.

RB : el contenido se carga mediante el script propio del sitio. En este caso, Context se usa para calcular el token de solicitud, que es igual a la página que contiene el script. Para el script site.net/1.js de la página de contexto de site.net, será igual al contexto de la página en sí.

Tenga en cuenta que el contexto de la página en sí no siempre es igual al nombre de dominio de la página y depende de cómo se abrió originalmente.

Suponga que el sitio del atacante evil.com abre la página del sitio atacado site.net, donde el script site.net/util.js ejecuta una solicitud con parámetros que pasan a través de la URL de la página. El atacante espera, al deslizar "sus parámetros" a través de la URL, forzar su propio script site.net/util.js para ejecutar una solicitud ajax para realizar acciones importantes en nombre de la víctima.

Supongamos que el usuario mismo fue a evil.com a través de un enlace directo. Entonces el contexto de evil.com será evil.com. Además evil.com abre el script site.net/api/payment?victim_params con un script , con la esperanza de llevar a cabo un ataque, pero el campo Contexto para site.net estará vacío (caso PE / PF). El script site.net/utils.js, al ejecutar una solicitud ajax, obligará al navegador a tomar Contexto de la página site.net. Y está vacío con nosotros. Pero entonces site.net recibirá una solicitud ajax con este token:

$$

mientras que para un usuario autorizado se espera:

$$

site.net verá un token desconocido y no podrá identificar al usuario. La protección funcionó.

Por cierto, hablando, debido a tal esquema, la realización de autorizaciones entre dominios a través de ventanas emergentes no será realista.

Para implementar SSO bajo el protocolo, debe abrir una nueva pestaña para la página del servidor de autorización. Y al mismo tiempo, el usuario debe abrir dicha pestaña. La mejor opción es abrir al usuario el enlace apropiado desde el sitio de destino.

RC : el contenido se carga con un script de sitio web externo. En este caso, el contexto se usa para calcular el token de solicitud, que es igual al campo Remitente de solicitud.

A pesar de que RA , RB y RC protegen contra los ataques CSRF, sin embargo conducen a la generación de tokens constantes. Y esto le permite implementar la autenticación entre dominios y la autenticación de usuarios entre dominios (cuando necesita determinar que varias solicitudes a diferentes servidores provienen de este usuario). Lo que se puede implementar para proporcionarle la misma autoridad en un grupo de dominios relacionados.

Si la página del sitio se abrió automáticamente desde otro sitio, no podrá iniciar sesión allí, incluso si vuelve a cargar este sitio usted mismo. Porque Source heredará de un valor nulo. El navegador debe indicarle al usuario sobre este hecho (Fuente = Aleatorio):

Esto se hace para proteger contra los sitios que obligan a abrir otras ventanas emergentes (ellos mismos o sus scripts externos), y en los sitios que se abren, se reiniciarán o crearán botones falsos de "cierre" en toda la pantalla que conducen a los mismos sitios. Es decir Esto evita un intento de rastrearlo, con la esperanza de obtener un token válido.

Cualquier intento por parte del sitio de imitar sus acciones con un script externo , o un intento de un script externo para crear directa o indirectamente una etiqueta de inicio y deslizarla hacia usted, conducirá a una Fuente vacía y a la adición de bytes aleatorios al momento de calcular el token hash.

El truco para crear o modificar la etiqueta <script> en la página atacada en el DOM no ayudará. El campo Fuente permanecerá en blanco.

Pero bajo las mismas condiciones, los scripts internos conducirán a consultas con Source igual a su valor anterior. Y si la página original tuviera Source = Domain, todo estaría bien. El usuario seguirá estando autorizado para tales solicitudes.

Pero con los scripts descargados de recursos de terceros (CDN), pueden surgir problemas en algunos casos. Y es correcto, porque La integridad del código CDN no está garantizada. Si no desea perder la autorización del usuario, mantenga los scripts en su sitio y descárguelos de su dominio. Esto es algo así como la prohibición de usar enlaces http en páginas https.

Describimos la situación en la que podría caer un desarrollador. Como resultado de las acciones del usuario, su script redirige a un usuario autorizado a una de las páginas del sitio (por ejemplo, esto se hace mediante un formulario), lo que requiere que el usuario permanezca autorizado. Su script llama, por ejemplo, $ (form) .submit () usando un script jQuery cargado desde el CDN. En este caso, el navegador ve que en la pila de llamadas que activó el evento de envío del formulario, hay una función de un script externo. Para evitar ataques XSS / CSRF , el navegador vacía el campo Fuente y agrega bytes aleatorios a la generación del token (caso P9 ). Como resultado, el usuario en la nueva página de repente queda sin autorización y no puede completar la operación. Esto puede ser confuso para los desarrolladores que están acostumbrados a usar CDN.

2.7 Escenarios de protocolo

Estos son los principales escenarios probables del usuario que trabaja con el sitio, que afectan todas las situaciones posibles y las etapas de su implementación (inicio de sesión anónimo, "recordarme", "olvidarme", cambiar a una clave permanente, autorización y salida, registro y autenticación de dos factores, exportación / importación de claves, reemplazo de claves, etc.)

.htaccess.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory> 

 cat /etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user 

2.7.1

K , «» T , . , : , . , vsphere.local, :

 Sender = Recipient = Context = vsphere.local 

() , :

$$

, . 128 , CSI-Salt ^* . , :

$$

Hi – 128 , Lo – 128 .
, , - , .. .

---

^{* . « ».}

2.8

( )

Permanent

. , , . – . CSI-Token-Action: success CSI-Token-Action: abort.

Logout

, . «» , ( ), (« »).

, , . .

Change-To

T, – '.

: T' ( , ), ( 128 ).

---

^{* , .}

2.9 -

, - -, . , site.ru img.site.ru, download.site.ru, .

site.ru -, . , site.ru, , - . .

, .
site.ru :

$$

, site.ru site.ru :

• ( )

T ₁ (. R1 , R4 , RB ). site.ru.

site.ru, download.site.ru. ( R1 , R4 ):

$$

download.site.ru , ajax- site.ru ( RB , RC ).

domain :

$$

, , , A, B, C . - . , .

site.ru ajax- . ID != T ₁ , site.ru. ID T _x . ID . ID .

. , , .. site.ru .

3

3.1

, , .

.

:

• ( )
• «» ( )

, - ( « » ), . , PIN-; .

- . : ?

, -, «», -, , , : « - ».

^* ( ). , . 100% , . , , , .

, (.. ). ( ) , – . - .

: + ( API ). « ». .

, , . , , , . : .

( ). , , .

---

^{*, 32- 64- . .}

3.2

. , .

. . :

1. , «» , , . , -, .
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . Es decir ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   , .
2. , .
3. , . Es decir ( SHA-2).
4. , , , . .

3.3 /

-?

, . ?

, . -, -, . .

, , ? , ( « »)? « » ?

, , , . , . , (email, mobile). , (, ). , , 100% , – .

-, -.

? , . , , bitcoin. , - . . . «», .

-?
. - ( ) , , , - . , . javascript. . …

-?

. . Tranquilo y silencioso. . . .

. , , , – . : , . , -.

. ( ). . IP- , , .

4

4.1

, , . -, . -, - – .

, , :

1. ( , ).
2. ( ) .

2 : , . == .

, № 2. «» ( ), «», , . , .

№ 1. .

1 H ₁ , 2, 1 – H ₂ . , (H ₁ , H ₂ ) -.
3, 2, . 3 H ₃ , 2, 3 – H _2' != H ₂ (. ). , , .. .

, fingerprint . , .

: , . .

4.2 XSS

XSS – , victim.com . , CDN .

. - ( ), ( ), ( ).

– Source .

: XSS ( ), . «». -.

4.3 SRF

evil.com, . (GET/POST/HEAD/PUT/DELETE) , (, ). (, ). , Referer . , .

CSRF , . . , . GET- ( ) .

.

4.4 SSO

S ₁ S ₂ , , , SSO, . .. (- ), ( ), S ₁ .

A, . S ₂ , ( S ₁ ) H ₁ . . S ₁ , S ₂ .

S ₂ .

 <meta http-equiv="refresh" content="0"> 

.

S ₂ A «»:

, . S ₂ H ₂ (.. 2.4 P1: ).

S ₂ S ₁ , H ₁ H ₂ , H ₂ S ₁ . S ₁ S ₂ , .. .

, .. , .

: . S ₂ , . , S ₁ S ₂ . .

4.5 SSO

, SSO, . .

.

.

, SSO, SSO. , . Es decir SSO – .

. .

- : Id- SSO . Id SSO . , .
(. « » ).

. , , SSO, - , .

. , – . - Id- . , , , .

: ( ). . . , . , , , .

. SSO ( , ). SSO ( !).

SSO (, ), .

4.6

, 100% . ( ), . .

SSL . HTTPS . , HTTP. .

, . .

– . , . . - , .

, , , Javascript . Cookie HttpOnly. ajax- .

: , , ( ). cookie .

: , , ; ( , ).

4.7

. . : , «». - – .

, -, .

, . . , .

, -: - .

, , , , . .

, , , -, :

$$

Conclusión

, , : « ?»


! Por desgracia , «/».

1. , , popup

« cookie! , ! «», ».

popup . GDPR ( ).

. , cookie ! «». , . , +1 .

2. . SSO : OAuth, SAML, Kerberos .., , , ; - SSO, : « , ». . . , … , . = .



3. . . , . -, - . -. ?

4. , . . .

5. . XSS, CSRF. - . — .

6. . .

7. , . , , , , , , , . SQL-.

, , . «» , - . . , «-» .

– ,
.

---

PS
. Habr . , () . sergey201991[]. , . / . . -.

, , :

1. , , ;
2. ; , SSO
3. «», - : - ( )
4. -

. 1 — , : , 1000. .

. 2 — . . , . 80- , .

, !