Generalmente, los sitios web tienen tres soluciones para defenderse de los ataques CSRF. (1) Verificar el valor del token. (2) Verifique el referente del encabezado HTTP. (3) Utilice XMLHttpRequest para adjuntarlo al encabezado. Los tres métodos anteriores se utilizan ampliamente, pero sus efectos no son tan satisfactorios. (¡Hay una sorpresa al final!)
1. Verificación de tokens
Adjuntar un fragmento de información a cada solicitud HTTP es una buena forma de defenderse contra ataques CSRF, porque puede determinar si la solicitud ha sido autorizada. Este "token de verificación" no debería ser fácilmente adivinado por usuarios que no hayan iniciado sesión. Si el token de verificación no está incluido en la solicitud o el token no coincide, el servidor debe rechazar la solicitud.
El método de verificación de token se puede utilizar para evitar el inicio de sesión CSRF, pero los desarrolladores a menudo se olvidan de verificar, porque si no hay inicio de sesión, el token CSRF no se puede vincular a través de la sesión. Si un sitio web quiere utilizar tokens de verificación para defenderse contra ataques CSRF de inicio de sesión, primero debe crear una "sesión previa" para que se pueda implementar la solución de defensa CSRF. Después de pasar la verificación, se crea una sesión real.
Diseño de fichas. Existen muchas técnicas para generar tokens de verificación.
• identificador de sesión. El método de almacenamiento de cookies del navegador es evitar que diferentes dominios accedan a las cookies de otros. Un enfoque común es utilizar directamente el identificador de sesión del usuario como token de verificación. El servidor hace coincidir el token del usuario con el identificador de sesión al procesar cada solicitud. Si el atacante puede adivinar el token del usuario, puede iniciar sesión en la cuenta del usuario. Y lo malo de hacer esto es que ocasionalmente el contenido que el usuario está navegando se enviará a un tercero, como cargar directamente el contenido de la página web a la base de datos de seguimiento de errores del fabricante del navegador a través del correo electrónico. Si esta página contiene el identificador de sesión del usuario, cualquiera que pueda ver esta página puede hacerse pasar por el usuario e iniciar sesión en el sitio web hasta que expire la sesión.
• Número aleatorio de sesión independiente. A diferencia del uso directo del identificador de sesión del usuario, cuando el usuario inicia sesión en el sitio web por primera vez, el servidor puede generar un número aleatorio y almacenarlo en la cookie del usuario. Para cada solicitud, el servidor hace coincidir el token con el valor almacenado en la cookie. Por ejemplo, el ampliamente utilizado sistema de seguimiento de problemas Trac utiliza esta tecnología. Sin embargo, este método no puede proteger contra ataques activos a la red, incluso si toda la aplicación web utiliza el protocolo HTTPS. Debido a que un atacante puede usar su propio token CSRF para sobrescribir esta sesión independiente, puede luego usar un token coincidente para falsificar una solicitud entre sitios.
• Depender del número aleatorio de la sesión. Una forma de mejorar la generación de números aleatorios es establecer una correspondencia entre el identificador de sesión del usuario y el token CSRF y almacenarlo en el servidor. Cuando el servidor procesa la solicitud, verifica si el token de la solicitud coincide con el identificador de sesión. Una desventaja de este método es que el servidor debe mantener una tabla de correspondencia grande (tabla hash).
• HMAC del identificador de sesión. Existe un método que no requiere que el servidor mantenga una tabla hash, que consiste en cifrar el token de sesión del usuario y usarlo como un token CSRF. Por ejemplo, los programas web Ruby on Rails generalmente usan este método y usan el HMAC del identificador de sesión como token CSRF. Siempre que todos los servidores del sitio web compartan la clave HMAC, cada servidor puede verificar que el token CSRF en la solicitud coincida con el identificador de sesión. Las características de HMAC garantizan que incluso si un atacante conoce el token CSRF del usuario, no puede inferir el identificador de sesión del usuario.
Con recursos suficientes, los sitios web pueden utilizar métodos HMAC para defenderse de los ataques CSRF. Sin embargo, muchos sitios web y algunos marcos de defensa CSRF (como NoForge, CSRFx y CSRFGuard) no pueden implementar correctamente una defensa de tokens relativamente sigilosa. Un error común es exponer tokens CSRF al manejar solicitudes entre sitios. Por ejemplo, si un sitio web confiable adjunta un token CSRF al realizar una solicitud a otro sitio web, ese sitio web puede falsificar una solicitud entre sitios al sitio web confiable.
Estudio de caso: NoForge.NoForge utiliza una tabla hash guardada en el servidor para verificar el token CSRF del usuario. Adjuntará un token CSRF cuando se envíen todos los enlaces y formularios. Hay tres razones por las que esta tecnología no es perfecta:
1. El HTML se crea dinámicamente en el navegador y no se volverá a agregar con tokens CSRF. Algunos sitios web crean HTML en el lado del cliente. Por ejemplo, Gmail, Flickr y Digg utilizan JavaScript para crear formularios, y estos formularios requieren medidas de defensa CSRF.
2. NoForge no distingue entre hipervínculos que apuntan a este sitio y sitios externos. Si hay un hipervínculo que apunta a un sitio externo, el sitio externo puede obtener el token CSRF del usuario en la solicitud. Por ejemplo, si phpBB implementa NoForge, una vez que el usuario hace clic en un enlace, el sitio conectado puede obtener el token CSRF del usuario. Incluso si NoForge distingue si es un enlace a este sitio o un enlace a un sitio externo, el Referer aún exponer al usuario token CSRF.
3. NoForge no tiene ningún efecto al iniciar sesión en CSRF, porque si el usuario ya tiene un identificador de sesión (ha iniciado sesión), NoForge solo verificará el token CSRF. Aunque este defecto se puede solucionar, también muestra que no es fácil implementar correctamente la estrategia de verificación de tokens.
Aunque las tres razones anteriores se pueden solucionar, estos defectos ilustran que es muy complicado implementar correctamente la estrategia de verificación de tokens. CSRFx y CSRFGuard y muchos otros sitios web ilustran este problema.
2. árbitro
En la mayoría de los casos, cuando el navegador inicia una solicitud HTTP, el Referer identifica dónde se inicia la solicitud. Si el encabezado HTTP contiene Referer, podemos distinguir si la solicitud se inicia en el mismo dominio o en varios sitios, porque Referer indica la URL que inició la solicitud. Los sitios web también pueden defenderse de los ataques CSRF determinando si la solicitud en cuestión se inicia desde el mismo dominio.
Desafortunadamente, a menudo los Referers contienen información confidencial que puede violar la privacidad del usuario. Por ejemplo, Referer puede mostrar búsquedas y consultas de usuarios en un sitio web privado. Aunque este contenido es bueno para los webmasters privados porque pueden utilizarlo para optimizar la clasificación en los motores de búsqueda, algunos usuarios todavía sienten que se viola su privacidad. Además, a muchas organizaciones también les preocupa que los referentes puedan filtrar información confidencial en la intranet.
lagunas jurídicas. Históricamente, las vulnerabilidades del navegador han hecho posible que los sitios web maliciosos engañen a los referentes, especialmente cuando utilizan servidores proxy. Muchas discusiones sobre la suplantación de Referer indican que los navegadores permiten falsificar Referer. Mozilla ha solucionado la vulnerabilidad de suplantación de identidad de Referer en Fire-fox 1.0.7. El IE actual todavía tiene vulnerabilidades en esta área, pero estas vulnerabilidades solo pueden afectar XMLHttpRequest y solo pueden usarse para falsificar Referer para saltar al propio sitio web del atacante.
escala. Si un sitio web elige utilizar Referer para defenderse de los ataques CSRF, el desarrollador del sitio web debe decidir si utilizará una estrategia de verificación de Referer más flexible o más estricta. Si se adopta una estrategia de verificación de Referer relajada, el sitio web debería bloquear las solicitudes con valores de Referer incorrectos. Si no hay ningún Referente en la solicitud, se aceptará la solicitud. Aunque este método es muy común, se puede evitar fácilmente. Porque el atacante puede eliminar el árbitro en el encabezado. Por ejemplo, las solicitudes iniciadas por FTP y URL de datos no incluyen Referer. Si se utiliza una estrategia estricta de verificación de Referer, el sitio web también bloqueará las solicitudes sin Referer. Esto es principalmente para evitar que los sitios web maliciosos oculten activamente Referers, pero también causará problemas de compatibilidad, como eliminar accidentalmente algunas solicitudes legítimas, porque algunos navegadores y configuraciones de red no incluyen Referers de forma predeterminada. Por lo tanto, esta carrera debe dominarse bien y, a menudo, depende de la experiencia. También discutiremos este tema en 4.2.1.
Estudio de caso: Facebook. En la mayoría de los sitios web de Facebook, la autenticación mediante token se utiliza para defenderse de los ataques CSRF. Sin embargo, el cuadro de inicio de sesión de Facebook utiliza una estrategia de verificación de referencia flexible. Este método no tiene ningún efecto ante ataques CSRF. Por ejemplo, un atacante podría redirigir al usuario desde http://attacker.com/ a ftp://attacker.com/index.html y luego iniciar una solicitud de inicio de sesión entre sitios a Facebook. Debido a que la solicitud proviene de una URL FTP, la mayoría de los navegadores no incluirán el Referer en la solicitud.
4.2.1 Experimento
Para evaluar la compatibilidad de la estricta estrategia de verificación de Referer, realizamos un experimento para medir la probabilidad y bajo qué circunstancias de que una solicitud legítima no contenga un Referer.
diseño. La publicidad es un canal conveniente para medir las características del navegador y de la red, por lo que podemos utilizar la publicidad como plataforma experimental. Entre el 5 y el 8 de abril de 2008, compramos 283.945 anuncios de 163.767 IP únicas en dos canales publicitarios diferentes. En el Canal A, compramos anuncios de banner web a un precio de 0,50 dólares por cada mil impresiones con las palabras clave "Firefox", "Juegos", "IE", "Video", "YouTube". En el canal B, publicamos anuncios intersticiales a 5 dólares de CPM con las palabras clave "ballet", "finanzas", "flores", "comida" y "jardinería". Gastamos $100 en cada canal publicitario, donde el canal A tuvo 241 483 clics (146 310 IP únicas) y el canal B 42 406 clics (18 314 IP únicas).
Los servicios de publicidad los brindan dos hosts en nuestro laboratorio y se compran dos nombres de dominio independientes de diferentes registradores. Cada vez que se muestra un anuncio, el anuncio genera un identificador específico en cada solicitud posterior y selecciona aleatoriamente un host como servidor maestro. El servidor principal envía el HTML del cliente a nuestro servidor a través de los protocolos HTTP o HTTPS, que pueden iniciar una solicitud GET o POST. Entre ellas, las solicitudes incluyen envíos de formularios, solicitudes de imágenes y XMLHttpRequests. El orden de las solicitudes es aleatorio y no tiene nada que ver con las acciones del usuario. Cuando el anuncio pasa la política de seguridad del navegador, inicia una solicitud del mismo dominio al servidor principal y una solicitud entre dominios al servidor secundario. El costo es de $400 por servidor, $7 por el dominio y es gratuito con un certificado HTTPS validado por dominio de 90 días obtenido de una autoridad certificadora legítima. El servidor registra los parámetros de la solicitud en función de la solicitud de red recibida, incluido el referente, el encabezado del agente de usuario, la fecha, la red Clase C del cliente y el identificador de sesión. El servidor también registra el valor de document.referrer a través de la API DOM, pero no registra la dirección IP del cliente. Para contar direcciones IP independientes, el servidor utiliza una CLAVE generada aleatoriamente en lugar de registrar HMAC. Esta CLAVE será descartada. La información registrada por el servidor no es suficiente para determinar por sí sola cuántos espectadores vieron el anuncio.
ética. El diseño del experimento siguió las reglas de los dos canales publicitarios. El comportamiento en el experimento es básicamente el comportamiento diario de los anuncios web, por lo que normalmente puede solicitar recursos adicionales a los anunciantes, como imágenes, audio y vídeo. Aunque la cantidad de solicitudes HTTP generadas por nuestros anuncios es mucho mayor que la de los anuncios normales, el ancho de banda que necesitamos es significativamente menor que el requerido por un anuncio de video. Nuestros servidores, al igual que los anunciantes, sólo registran la información que ellos registran. En realidad, nuestros servidores registran mucha menos información que los anunciantes comerciales porque no registramos las direcciones IP de los clientes.
resultado. Hemos resumido los resultados en las Figuras 2 y 3. También encontramos que los siguientes resultados son solo un 95% confiables.
• En el método HTTP, las solicitudes entre dominios no contienen el encabezado Referer con mayor frecuencia que en las solicitudes del mismo dominio, mientras que en el método POST (coeficiente chi-cuadrado = 2130, valor p <0,001) y el método GET (coeficiente chi-cuadrado = 2130, valor p <0,001). coeficiente cuadrado = 2175, valor p <0,001), el primero no contiene el encabezado Referer es más común.
• En las estadísticas que no incluyen el encabezado Referer, HTTP es más común que HTTPS, incluidas las solicitudes POST (coeficiente de chi-cuadrado = 6754, valor p <0,001) entre dominios y GET (coeficiente de chi-cuadrado = 6940) entre dominios. , valor p <0,001), solicitudes POST del mismo dominio (coeficiente de chi-cuadrado = 2286, valor de p <0,001) y solicitudes GET del mismo dominio (coeficiente de chi-cuadrado = 2377, valor de p <0,001).
• En las estadísticas que no incluyen el encabezado Referer, todas las formas de solicitudes del canal publicitario B son más comunes que las del canal publicitario A. Estos formularios de solicitud incluyen: POST entre dominios HTTP (coeficiente de chi-cuadrado = 3060, valor p <0,001), POST del mismo dominio HTTP (coeficiente de chi-cuadrado = 6537, valor p <0,001), POST entre dominios HTTPS (coeficiente de chi-cuadrado = 49,13, valor de p <0,001) y solicitudes POST HTTPS del mismo dominio (coeficiente de chi-cuadrado = 44,52, valor de p <0,001).
• También contamos los encabezados personalizados X-Requested-By (consulte la Sección 4.3) y Origin (consulte el Capítulo 5). X-Requested-By tiene alrededor del 0,029 % al 0,047 % de las solicitudes HTTP POST y del 0,084 % al 0,112 % de las HTTP. Las solicitudes GET, del 0,008 % al 0,018 % de las solicitudes HTTPS POST y del 0,009 % al 0,020 % de las solicitudes HTTPS GET no contienen el encabezado Referer. Origin no incluye el encabezado Referer en la misma solicitud anterior.
Figura 2. Solicitudes sin referente y referente incorrecto (283.945 resultados). xey representan los nombres de dominio del servidor primario y del servidor secundario respectivamente.
conversar. Hay dos pruebas sólidas a continuación que muestran que las solicitudes que no incluyen un Referer generalmente provienen de la red (ataque) en lugar del navegador.
1. Es más común que las solicitudes HTTP no contengan Referer que las solicitudes HTTPS porque el proxy de red puede eliminar el encabezado en la solicitud HTTP, pero no puede eliminar el encabezado en la solicitud HTTPS. Por supuesto, en algunas redes empresariales, algunos terminales HTTPS son servidores proxy de red. En este caso, el proxy puede modificar las solicitudes HTTPS, pero esta situación es relativamente rara.
2. Cuando el navegador elimina el Referer, también eliminará el valor de document.referrer. Sin embargo, si el Referer se elimina de la red, document.referrer seguirá ahí. Sin embargo, descubrimos que la eliminación de Referer es más común que la eliminación de document.referrer.
De hecho, en el experimento, el valor document.referrer se eliminó principalmente debido a dos navegadores especiales: el navegador de PlayStation 3 no admite document.referrer y Opera eliminó document.referrer (pero no Referer) para HTTPS entre sitios. preguntar. La mayor proporción de eliminación de Referer en XMLHttpRequest se debe a errores en Firefox 1.0 y 1.5. Todos estos resultados indican que solo una cantidad muy pequeña de navegadores están configurados para no enviar referencias.
También hay evidencia de que el Referer fue eliminado debido a problemas de privacidad. Cuando el navegador envía el Referer del sitio web A al sitio web B, la privacidad del usuario también queda expuesta, porque el sitio web B puede recopilar la navegación del usuario en el sitio web A a través del Referer. . Por el contrario, enviar Referers bajo el mismo dominio no causa problemas de privacidad, porque el sitio web puede recopilar la privacidad del usuario a través de cookies (es decir, no es necesario recopilarla a través de Referers). También descubrimos que las solicitudes entre sitios bloquean a más Referentes que las solicitudes en el mismo sitio, lo que indica que, debido a preocupaciones de privacidad, se bloquea artificialmente el envío de los Referentes.
De esto sacamos dos conclusiones principales:
1. Defienda CSRF a través de HTTPS. En solicitudes HTTPS, Referer se puede utilizar para evitar CSRF. Para implementar la estrategia de utilizar referentes para prevenir CSRF, el sitio web debe rechazar las solicitudes que no tienen un referente, porque un atacante puede controlar el navegador para eliminar el referente. En HTTP, el sitio web no puede rechazar ciegamente solicitudes sin un Referer, porque considerando la compatibilidad, es posible que una gran cantidad de usuarios (alrededor del 3 al 11%) no puedan acceder al sitio web. La diferencia es que en HTTPS se puede implementar una estrategia estricta de verificación del Referer, porque solo una pequeña parte (0,05–0,22%) de los navegadores eliminarán el Referer. En particular, cabe señalar que la estricta estrategia de verificación del Referer es muy adecuada para evitar el inicio de sesión CSRF, porque normalmente las solicitudes de inicio de sesión se inician a través del protocolo HTTPS.
2. Cuestiones de privacidad. Una política de referencia estricta es una excelente defensa para el CSRF porque es fácil de implementar. Desafortunadamente, las políticas de privacidad pueden impedir que este esquema despegue. Por lo tanto, las nuevas funciones de seguridad de los navegadores y los nuevos mecanismos de defensa CSRF deben resolver primero los problemas de privacidad antes de poder implementarlos a gran escala.
Figura 3. Solicitudes sin referente y con referente incorrecto en el canal publicitario A (241,483 resultados). Opera bloquea document.referrer HTTPS entre sitios, Firefox 1.0 y 1.5 no envían Referer durante XMLHttpRequest debido a errores, y PlayStation 3 (PS en la imagen) no admite document.referrer.
3. Personaliza el encabezado HTTP
También podemos usar encabezados HTTP personalizados para defendernos contra ataques CSRF, porque aunque el navegador evitará que se envíen encabezados HTTP personalizados a sitios externos, permite enviar encabezados HTTP personalizados a este sitio a través de XMLHttpRequest. Por ejemplo, la biblioteca JavaScript prototipo.js usa este método y agrega el encabezado X-Requested-By a XMLHttpRequest. Google Web Toolkit también recomienda que los desarrolladores agreguen un encabezado X-XSRF-Cookie a XMLHttpRequest para defenderse contra ataques CSRF, donde XMLHttpRequets contiene valores de cookies. Por supuesto, no es necesario utilizar las cookies en XMLHttpRequets para defenderse contra CSRF, porque solo la parte del encabezado es suficiente.
Cuando se utiliza este método para defenderse contra ataques CSRF, el sitio web debe usar XMLHttpRequest y agregar un encabezado personalizado (como X-Requested-By) en todas las solicitudes, y rechazar todas las solicitudes sin un encabezado personalizado. Por ejemplo, para defenderse contra ataques CSRF de inicio de sesión, el sitio web debe enviar la información de autenticación del usuario al servidor a través de XMLHttpRequest. En nuestros experimentos, aproximadamente entre el 99,90% y el 99,99% de las solicitudes recibidas por el servidor contienen el encabezado X-Requested-By, lo que demuestra que este método es adecuado para la gran mayoría de usuarios.
ruta de aprendizaje
Para los estudiantes que nunca han estado expuestos a la seguridad de la red, hemos preparado una hoja de ruta detallada de aprendizaje y crecimiento para ustedes. Se puede decir que es la ruta de aprendizaje más científica y sistemática, y no será ningún problema para todos seguir esta dirección general. (Puedes dejar un mensaje en el área de comentarios si es necesario)
Al mismo tiempo, se proporcionan vídeos de apoyo para cada tramo correspondiente a la ruta de crecimiento:
