Curso MIT "Seguridad de sistemas informáticos". Lección 9: Seguridad de aplicaciones web, Parte 3

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3
Lección 5: “¿De dónde vienen los sistemas de seguridad?” Parte 1 / Parte 2
Lección 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Lección 7: “Sandbox de cliente nativo” Parte 1 / Parte 2 / Parte 3
Lección 8: "Modelo de seguridad de red" Parte 1 / Parte 2 / Parte 3
Lección 9: "Seguridad de aplicaciones web" Parte 1 / Parte 2 / Parte 3

Público: ¿qué impide que un atacante encuentre una clave? ¿Dónde se encuentra esta clave secreta?



Profesor: sí, esa es una buena pregunta. En la mayoría de los casos, el cliente para AWS no es un navegador, sino algunas máquinas virtuales que se ejecutan en la nube. Por lo tanto, solo ve comunicación entre máquinas virtuales. También puede imaginar que los usuarios de alguna manera pueden entregar estos enlaces o incrustarlos de alguna manera en HTML. Si tiene algo como el que se muestra en la pizarra dentro del código fuente HTML o JavaScript, tendrá el código para crear dicha solicitud. Por lo tanto, si le proporciono una de estas cosas, puede hacer una solicitud en mi nombre.

Audiencia: ¿Es posible usar MAC para clientes normales?

Profesor: para normal, ¿te refieres a los navegadores?

Audiencia: para usuarios comunes.

Profesor: el hecho es que la cuestión de dónde vive realmente la clave es crucial. Porque si la llave se puede robar tan fácilmente como las cookies, entonces no ganamos nada. Por lo tanto, en muchos casos, todas estas cosas se almacenan en algún lugar de la nube y sirven para intercambiar datos entre máquinas virtuales y se transmiten de un servidor a otro también en la nube. Por lo tanto, el desarrollador de la aplicación lanza la VM, que utiliza la externalización de un montón de cosas almacenadas en AWS.

Audiencia: ¿Hay un problema de retraso de red aquí, por lo que el atacante puede enviar la misma solicitud inmediatamente después del usuario y también obtener acceso?

Profesor: sí, basta con decir que varias personas defendieron disertaciones sobre el tema de la seguridad de las marcas de tiempo. Pero tiene toda la razón, porque hemos considerado un ejemplo bastante burdo.



Imagine que aquí, en este ejemplo de Cadena para firmar, en la línea FECHA, tendremos el valor "Lunes 4 de junio". Luego, si de alguna manera el atacante puede obtener acceso a todo esto, podrá repetir la solicitud del usuario. El hecho es que AWS le permite usar la fecha de vencimiento de estas cosas. Por lo tanto, una cosa que puede hacer es agregar el campo Caduca aquí, y asumiremos que se ha establecido una fecha de vencimiento.



Entonces puedo dar este enlace a un grupo de personas diferentes, y el servidor verificará si sus solicitudes han expirado.

Público: incluso si la fecha de vencimiento es de solo 200 milisegundos, pero el atacante está monitoreando la red, podrá enviar por si acaso varias copias de la solicitud en lugar de una.

Profesor: es absolutamente cierto que si el atacante ataca la red y ve cómo se transmiten estas cosas por cable, y hay suficiente espacio para maniobrar en la fecha de vencimiento, entonces definitivamente puede realizar este ataque.

Así que esta fue una descripción general de cómo funcionan las cookies sin estado. Esto plantea una pregunta interesante: ¿qué significa cerrar sesión con cookies de este tipo? La respuesta es que realmente no vas a salir. Quiero decir, tienes esta clave y cada vez que quieras enviar una solicitud, simplemente la envías. Pero el servidor podría revocar su clave.

Supongamos que el servidor revocó la clave. Pero puede crear una de estas cosas GET, y cuando envíe un mensaje al servidor, dirá: "Sí, ya conozco su ID de usuario, la clave ha sido revocada, por lo que no cumpliré su solicitud". Sin embargo, hay matices, y si hablamos de cosas como SSL, empoderar a una persona es mucho más fácil que recordarlo.

Como tal, hay varias otras cosas que puede usar si desea evitar las cookies tradicionales para implementar la autenticación. Uno de ellos es el uso de DOM - almacenamiento, que contiene información sobre la autenticación del lado del cliente. Puede usar el repositorio DOM para almacenar algunos estados de sesión que generalmente se colocan dentro de las cookies.



Si recuerda de la última conferencia, el repositorio DOM es una interfaz clave de los valores que el navegador proporciona a cada fuente, es decir, el navegador los toma de allí y los inserta en una cadena.

Lo bueno es que el DOM no tiene reglas tan estúpidas con respecto a las mismas políticas del mismo origen. Entonces, si se tratara de cookies normales, podría hacer todos estos trucos de subdominio y similares. El repositorio DOM está estrictamente vinculado a una sola fuente, por lo que no puede extender ningún subdominio. Por lo tanto, los marcos como Meteor usan este almacenamiento.

Pero tenga en cuenta que si desea guardar la información de autenticación en el repositorio DOM, deberá escribir el código JavaScript usted mismo para transferir esta información al servidor, cifrarla, etc. Esto es lo que debe hacer en este caso.
Uno podría usar certificados del lado del cliente, por ejemplo, el formato x.509, que contiene información sobre el propietario, una clave pública, información sobre una autoridad de certificación y una firma digital electrónica. Lo bueno de estos certificados es que JavaScript no tiene una interfaz explícita para acceder a estas cosas. Entonces, a diferencia de las cookies, donde siempre hay una "carrera armamentista" para encontrar errores de política del mismo origen, los certificados no tienen una interfaz JavaScript explícita para esto. Esto es muy bueno desde el punto de vista de la seguridad.

Uno de los problemas que mencioné brevemente y que discutiremos en detalle en conferencias posteriores es la revocación de certificados. Si un usuario deja su organización, ¿cómo puede obtener un certificado de él? Esto es bastante complicado.



Además, estas cosas no son muy convenientes de usar, porque nadie quiere instalar un montón de certificados para cada sitio que visita. Por lo tanto, los certificados de autenticación no son muy populares, con la excepción de las compañías u organizaciones responsables de la seguridad con gran responsabilidad. Esto concluye nuestra discusión sobre las cookies.

Ahora hablemos de las vulnerabilidades del protocolo en la pila web. Uno de los tipos de ataques interesantes es utilizar errores en los componentes del navegador, por ejemplo, al analizar URL. Entonces, ¿cómo puede el análisis de URL causarnos problemas?

Supongamos que tenemos una URL del tipo donde se insertan caracteres extraños al final por alguna razón:

ejemplo.com : 80 @ foo.com.

La pregunta es, ¿cuál es el origen de esta URL en particular? Flash habría pensado que el nombre de host es example.com. Pero cuando el navegador analiza la dirección, pensará que el origen del host en este caso es foo.com.



Esto es muy malo, porque cuando tenemos dos entidades diferentes que están confundidas sobre el origen del mismo recurso, está lleno de problemas desagradables.
Por ejemplo, un código flash puede ser malicioso y descargar algún material de example.com. Si el exploit se incorporó a la página con foo.com, también podría hacer algunas cosas malas allí. Y luego toma un código de example.com y lo ejecuta con los poderes de foo.com. Muchas reglas de análisis complejas como estas hacen que la vida sea muy difícil. Sucede todo el tiempo.

Acabamos de examinar la desinfección del contenido, cuya idea principal es que a menudo es mucho mejor cuando hay reglas de análisis más simples para este tipo de cosas. Sin embargo, retrospectivamente, esto es difícil de hacer, porque el HTML ya está ahí.
Ahora hablemos de mi vulnerabilidad de seguridad favorita: archivos con la extensión .jar, que son un archivo ZIP con parte de un programa Java. Los archivos JAR del navegador se convierten en el objetivo del ataque, principalmente los applets de Java. Alrededor de 2007, un excelente sitio llamado lifehacker.com explicó cómo incrustar archivos zip dentro de las imágenes. Al hacer esto, no está claro de quién estás tratando de esconderte, pero lifehacker.com se asegura de que puedas hacerlo.

Utilizan principalmente el hecho de que si observa formatos de imagen, como GIF, entonces, como regla, el analizador funciona de arriba a abajo. Primero encuentra la información en el encabezado, y luego mira los bits restantes ubicados en la parte inferior.



Al final resultó que, los programas que generalmente manipulan archivos ZIP funcionan de abajo hacia arriba, es decir, lo contrario de la dirección del análisis de imágenes. Primero, encuentran la información en el pie de página del archivo y desempacan lo que está dentro del archivo. Por lo tanto, si coloca un archivo de imagen que contiene un archivo ZIP, pasará todas las comprobaciones, incluso la comprobación de Flickr, como cualquier otra imagen, e incluso aparecerá como una imagen en su navegador.

Pero solo tú conocerás la verdad oculta. Solo usted sabrá que si toma este archivo, puede descomprimirlo y usar la información contenida allí. Parece un truco barato, pero los hackers nunca duermen, constantemente quieren arruinar nuestras vidas. Entonces, ¿cómo implementan esta idea?

Entienden que los archivos JAR se derivan del formato .zip. Esto significa que puede crear una animación GIF o una imagen estática que tenga un archivo JAR, es decir, un código ejecutable de JavaScript, en la parte inferior.

Más tarde, la gente llamó a este método de ataque GIFAR, mitad GIF, mitad JAR, y ambas mitades son malvadas. Fue asombroso. Cuando las personas descubrieron por primera vez tal oportunidad, la encontraron increíble, pero no entendieron en absoluto cómo usarla. Pero resultó que, sobre la base, se pueden hacer las siguientes cosas.



Entonces, ¿cómo puedes hacer esto? Solo usas CAD. Toma .gif, toma .jar, usa el archivo autoextraíble: ¡boom, y GIFAR te atacó!

Entonces, una vez que tienes esto, ¿qué puedes hacer? Hay algunos sitios confidenciales que permiten a los usuarios proporcionar datos, pero no tipos de datos arbitrarios. Por lo tanto, Flickr o algo así puede no permitirle enviar ActiveX arbitrario o cualquier otro HTML arbitrario. Pero se te permitirá enviar imágenes. Por lo tanto, puede crear una de estas cosas y enviarla a uno de estos sitios confidenciales que le permite enviar imágenes. ¿Qué necesita hacer para llevar a cabo un ataque exitoso en este caso?



En primer lugar, envíe esta imagen "rellena" a uno de estos sitios. En segundo lugar, utilice el método de ataque de secuencias de comandos entre sitios XSS, utilizando las vulnerabilidades existentes. Para hacer esto, debe insertar el applet, escribiendo en JavaScript tal expresión:

Este código explota la vulnerabilidad de secuencias de comandos entre sitios, por lo tanto, se lanzará en el contenido del sitio. GIFAR pasará la verificación de origen, ya que proviene de un sitio con una fuente de origen común, a pesar de que este código fue insertado por un atacante.

Entonces, ahora el atacante tiene la oportunidad de ejecutar este applet de Java en el contexto del sitio de la víctima con todos los permisos de origen. Y una de estas cosas se identificará correctamente como una imagen GIF. Pero hay un código oculto aquí. Permítame recordarle que al principio el navegador descomprime los archivos archivados, por lo tanto, primero que nada, lanzará la parte JAR, ignore la parte superior del GIF. Así que esto es realmente asombroso.

Hay algunas formas bastante simples de solucionar esto. Por ejemplo, puede usar el cargador de applets, que comprende que no debe haber basura aleatoria. En muchos casos, se utiliza información de metadatos que muestra la longitud de este recurso. En este caso, el cargador comenzará, como se esperaba, desde la parte superior, analizará su longitud, verá que el applet termina en la parte superior y se detendrá. No le importa la parte inferior, es posible que sea incluso 0. En nuestro caso, dicho cargador no ayudará, ya que comenzará a procesar la solicitud desde la parte inferior archivada y se detendrá frente a la superior, ignorándola.

Lo que me gusta de esto es que realmente muestra cuán amplia es la pila de software de Internet. Tomando solo estos dos formatos, GIF y JAR, puede crear un ataque realmente desagradable.

Puede hacer lo mismo con los archivos PDF. Puede poner un PDF en lugar de un GIF y llamar a este ataque algo de los peligros de PDFAR. Pero al final, la gente descubrió este problema y ahora se eliminan las vulnerabilidades de este tipo.

Público: ¿Qué puede hacer con este tipo de ataque, que no se puede hacer con un ataque de secuencias de comandos entre sitios XSS?

Profesor: Esta es una buena pregunta. Entonces, lo bueno de esto es que Java a menudo puede ser una herramienta más poderosa que JavaScript normal, porque usa reglas ligeramente diferentes, la misma política de origen y similares. Pero tiene razón en que si puede ejecutar secuencias de comandos entre sitios, ejecutar JavaScript usted mismo puede ser bastante perjudicial. Pero la principal ventaja de este método es que esta tecnología de ataque funciona dentro del applet y puede hacer lo que no puede hacer con el código de script malicioso ordinario.

Entonces, como dije, este es mi ataque favorito de todos los tiempos, principalmente porque hizo que la gente de seguridad informática de buena reputación piense en una palabra como GIFAR.

Otra cosa interesante es el uso de ataques basados ​​en el tiempo. Por lo general, las personas no piensan en el tiempo como un recurso, que puede ser un vector para los ataques. Pero como señalé hace unos minutos, ese tiempo en realidad puede ser un medio para introducir una vulnerabilidad en el sistema.

El ataque específico del que voy a hablar contigo es el ataque del canal secreto. La idea de este ataque es que un atacante encuentra una manera de intercambiar información entre dos aplicaciones, y esta operación de intercambio no está autorizada. Un atacante está utilizando de alguna manera alguna parte del sistema para transferir bits de información entre dos recursos diferentes.

Un buen ejemplo de tal cosa es un ataque de detección de CSS. ¿Qué es tal ataque?

Supongamos que un atacante tiene un sitio web que un usuario puede visitar. Hacer que un usuario visite un sitio web es realmente bastante simple. Crea un anuncio o envía un correo electrónico de phishing.

Por lo tanto, el atacante tiene un sitio web que visita el usuario. Y el objetivo del atacante es averiguar qué otros sitios ha visitado el usuario. Un atacante podría querer saber esto por varias razones. Quizás esté interesado en las consultas de búsqueda del usuario, o esté tratando de averiguar dónde trabaja esta persona, o tal vez quiera saber si esta persona está visitando algunos sitios "vergonzosos", etc.



¿Cómo va a hacer esto un atacante si lo único que controla es un sitio web que quiere convencer a un usuario para que visite? Una forma posible es usar colores de enlace. Como sabe, si siguió un enlace una vez, la próxima vez que aparezca en su navegador en un color diferente, indica que ya ha realizado la transición a este enlace. Esto es en realidad una vulnerabilidad de seguridad.

Debido a que esto significa que en su sitio, un atacante puede generar una gran lista de posibles URL que puede visitar, y luego usar JavaScript para ver qué color adquirieron estas URL. Y si el color del enlace URL es morado, significa que ha visitado este sitio. Así que este es un truco bastante sutil.

Lo interesante es que, en muchos casos, ni siquiera necesita mostrar las URL. Puede organizar los enlaces en forma de encabezados en la pantalla según el tipo de dominó, y estos encabezados cambiarán de color si el usuario usa este enlace. ¿Quizás piense que es demasiado tedioso rastrear todas estas URL de sitios visitados por el usuario? Pero este proceso puede optimizarse mediante el uso de varios pasajes filtrados a través de la lista de direcciones. Por ejemplo, primero puede ver si el usuario ha visitado la URL de nivel superior: cnn.com, Facebook.com, y así sucesivamente. Si la respuesta es sí, puede seleccionar las páginas de nivel superior más visitadas. De esa manera realmente puede limitar su búsqueda.

Entonces, la función inofensiva que admiten los navegadores para ayudar al usuario, diciendo: "¡Hola, amigo, aquí es donde fuiste!"



¿Cómo puedo evitar un ataque de canal encubierto? En la práctica, se hace para que el navegador simplemente engañe a JavaScript sobre el color correcto de los enlaces. JavaScript , , . , . , , JavaScript , . , , ? , .

, , — . – , .

, , . , , .



, — , , , , , . , , , , . ?

, . . , .

, Google Map Tiles. , «» Google Map, , , , . .

? , . , , , . , .

, , , JavaScript . , , DNS.
: , , DNS , . , , -, , -. , , DNS . , , DNS , .



: JavaScript .

: , !

: , , , , ?

: , . , — - , , , - URL. , API– , .

: - , , ?
: . , API — . , ? , DNS , .

, , IP — ? ! , JavaScript . . , , ! .

La idea principal aquí es representar la URL que visitó anteriormente más rápido.

       <iframe>,    , ,   , , , ,    ,        <iframe>.     <iframe> ,   ,   <iframe>      .       ,    origin,        . 

Por lo tanto, el atacante ya no puede tocar nada y concluye que pudo determinar el sitio que visitó anteriormente.

¡Nos vemos en la próxima conferencia!


La versión completa del curso está disponible aquí .

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps hasta diciembre de forma gratuita al pagar por un período de seis meses, puede ordenar aquí .

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?