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

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

Por ejemplo, Django tomará estos corchetes angulares, los traducirá a formato HTML y rehacerá el resto de los caracteres. Es decir, si el valor del nombre personalizado contiene corchetes angulares, comillas dobles y similares, se excluirán todos estos caracteres. Hará que el contenido no se interprete como código HTML en el lado del navegador del cliente.



Así que ahora sabemos que esta no es una defensa muy confiable contra algunos ataques de secuencias de comandos entre sitios. La razón, como mostramos en el ejemplo, es que estas gramáticas para HTML, CSS y JavaScript son tan complejas que pueden confundir fácilmente el analizador del navegador.

Por ejemplo, tenemos algo muy común hecho en el marco de Django. Entonces, tiene alguna función div, y queremos establecer una clase dinámica para ello. Le damos a la clase el valor de var, y así sucesivamente. La idea es que cuando Django procesa esto, necesita descubrir cuál es el estilo actual y luego pegarlo aquí.

En este caso, un atacante puede crear una cadena que define esta clase, por ejemplo, escribe "clase 1". Todo va bien hasta este punto, porque parece una expresión CSS válida.

Pero entonces el atacante coloca el operador onclick aquí, que es igual al código JavaScript que hace que el sistema llame.



Como esto está mal, el navegador debería detenerse aquí. Pero el problema es que si alguna vez has visto el HTML de una página web real, todo está roto y confundido, incluso para sitios legítimos y "amigables". Entonces, si el navegador se detiene antes de cada expresión HTML errónea, ni un solo sitio que te guste nunca funcionará. Si alguna vez quieres decepcionarte en el mundo y no te he ayudado lo suficiente, solo abre la consola de JavaScript en tu navegador cuando veas el sitio para ver cuántos errores te dará.

Puede, por ejemplo, ir a CNN y ver cuántos errores obtiene. Sí, básicamente CNN funciona, pero de manera muy desigual. Por ejemplo, para abrir Acrobat Reader, constantemente debe lanzar excepciones de puntero nulo, y al mismo tiempo se sentirá un poco engañado por la vida. Pero en Internet, hemos aprendido a aceptar esto sin mucha indignación.
Por lo tanto, dado que los navegadores deben ser muy tolerantes con tales cosas, intentarán convertir el código malicioso en algo que les parezca razonable. Y esa es la vulnerabilidad de seguridad.

Así es como funciona la desinfección de contenido, y aún es mejor que nada. Puede atrapar muchas cosas dañinas, pero no puede defenderse de todo.

Hay una cosa más en la que pensar: el uso de un lenguaje de marcado menos expresivo. Veamos qué significa.

Público: ¿qué debo hacer si la limpieza de contenido no funciona?

Profesor: sí, esto es posible, por ejemplo, en este caso Django no podrá determinar estáticamente que es malo. Por ejemplo, en este caso particular. Pero en el caso cuando inserto una etiqueta de imagen maliciosa ...

Público: en este caso particular, esperaría que la asignación de clase esté entre comillas y en este caso no debería tener ningún efecto ...

Profesor: bueno, ya ves, hay pequeños trucos. Suponiendo que la gramática de HTML y CSS esté cuidadosamente definida, puede imaginar un mundo en el que los analizadores ideales podrían detectar de alguna manera estos problemas o transformarlos de alguna manera en cosas normales. Pero, de hecho, la gramática HTML y la gramática CSS sufren imprecisiones. Además, los navegadores no implementan especificaciones. Por lo tanto, si usa una gramática menos expresiva, será mucho más fácil para nosotros desinfectar el contenido.

Aquí se usa el término Markdown - "marcado fácil de leer" en lugar del término marcado - marcado ordinario. La idea principal de Markdown es que está diseñado como un lenguaje que, por ejemplo, permite a los usuarios publicar comentarios, pero no contiene la capacidad de usar una etiqueta vacía, soporte de applet y similares. Por lo tanto, en Markdown en realidad es mucho más fácil identificar de forma exclusiva la gramática y luego simplemente aplicarla.



La desinfección es mucho más fácil en un lenguaje simple que en HTML, CSS y JavaScript completos. Y en cierto modo, esto es como la diferencia entre comprender el código C y el código Python. Realmente hay una gran diferencia en la comprensión de un lenguaje más expresivo. Por lo tanto, al limitar la expresividad, a menudo mejora la seguridad.

Para protegerse contra ataques de secuencias de comandos entre sitios, también se utiliza CSP, Política de seguridad de contenido. La idea de CSP es que permite que el servidor web ...
Público: Tengo curiosidad por saber acerca de este lenguaje Markdown. ¿Todos los navegadores pueden realizar el análisis de idiomas?

Profesor: no, no, no. Simplemente puede convertir varios tipos de idiomas a HTML, pero los navegadores no los entienden en su forma original. En otras palabras, tiene un sistema de comentarios y utiliza Markdown. Es decir, los comentarios, antes de mostrarse en la página, van al compilador Markdown, que los traduce al formato HTML.

Público: ¿por qué no usar siempre Markdown?

Profesor: Markdown le permite usar HTML incrustado, y que yo sepa, hay una manera de deshabilitarlo en el compilador. Pero podría estar equivocado sobre eso. El hecho es que no siempre es posible usar un lenguaje limitado, y no todos quieren hacerlo.

Entonces, continuemos la discusión sobre cómo aumentar la seguridad con la ayuda de la Política de seguridad de contenido. Esta política permite que el servidor le diga al navegador web qué tipos de contenido se pueden cargar en la página que envía, así como también de dónde debe provenir este contenido.

Por ejemplo, en la respuesta HTTP, el servidor puede usar algo como esto: incluye el encabezado Contenido - Seguridad - Política, la fuente predeterminada es propia y recibirá datos de * .midominio.com.



Con el operador propio, el servidor indica que el contenido de este sitio debe provenir únicamente del dominio de una página en particular o de cualquier subdominio de mydomain.com. Esto significa que si tuviéramos un enlace automático a foo.com, el servidor enviaría esta página nuevamente al navegador.

Supongamos que un ataque de secuencias de comandos en sitios cruzados intenta crear un enlace a bar.com. En este caso, el navegador verá que bar.com no es propio y no es un dominio de midominio.com, y no saltará más esta solicitud. Este es un mecanismo bastante poderoso en el que puede especificar controles más detallados. Establece parámetros que indican que sus imágenes deben provenir de tal y tal fuente, secuencias de comandos de tal y tal, etc. En realidad es conveniente.

Además, esta política en realidad evita JavaScript incrustado, por lo que no puede abrir la etiqueta, escribir algún tipo de secuencia de comandos y cerrar la etiqueta, porque todo lo que puede ir al navegador debe provenir solo de una fuente condicional. CSP previene cosas peligrosas como usar el argumento de la función eval (), que permite que una página web ejecute código JavaScript generado dinámicamente. Entonces, si el encabezado CSP está configurado, el navegador no ejecutará eval ().

Audiencia: ¿ Eso es todo lo que protege CSP?

Profesor: no. Hay una lista completa de recursos que realmente protege, y puede configurar la protección contra muchas cosas no deseadas, por ejemplo, especificar dónde está permitido aceptar CSS salientes y muchas otras cosas.

Audiencia: ¿ Pero además de eval () hay otras cosas que amenazan la seguridad?

Profesor: sí, existen. Por lo tanto, siempre surge la cuestión de la integridad de la protección. Entonces, por ejemplo, no solo eval puede generar dinámicamente código JavaScript. También hay un constructor de funciones, hay ciertas formas de llamar a un tiempo de espera determinado, vas a la línea y puedes analizar el código de esta manera. CSP puede deshabilitar todos estos peligrosos vectores de ataque. Pero esto no es una panacea para el aislamiento completo de exploits maliciosos.

Audiencia: ¿Es cierto que CSP se puede configurar para evitar que se verifiquen todos los scripts internos en la página?

Profesor: sí, ayuda a evitar la ejecución de código generado dinámicamente, mientras que el código incrustado debe ignorarse. El navegador siempre debe obtener el código del atributo de origen. En realidad, no sé si todos los navegadores hacen esto. La experiencia personal muestra que los navegadores exhiben comportamientos diferentes.

En general, la seguridad de Internet es similar a las ciencias naturales, por lo que las personas simplemente presentan teorías sobre cómo funcionan los navegadores. Y luego ves cómo sucede esto realmente. Y la imagen real puede decepcionar, porque nos enseñan que hay algoritmos, evidencia y similares. Pero estos navegadores se comportan tan mal que los resultados de su trabajo son impredecibles.

Los desarrolladores de navegadores intentan estar un paso por delante de los atacantes, y más adelante en la conferencia verán ejemplos de esto. De hecho, CSP es algo muy bueno.

Otra cosa útil es que el servidor puede establecer un encabezado HTTP llamado X-Content-Type-Options, cuyo valor es insignificante.



Este encabezado evita que MIME descarte la respuesta del tipo de contenido anunciado, ya que el encabezado le dice al navegador que no anule el tipo de contenido de respuesta. Con la opción nosniff, si el servidor dice que el contenido es text / html, el navegador lo mostrará como text / html.
En pocas palabras, este encabezado evita que el navegador "olfatee" la respuesta del tipo de contenido declarado para que la situación no ocurra cuando el navegador dice: "sí, olfateé la falta de coincidencia entre la extensión del archivo y el contenido real, por lo que convertiré este contenido en otro contenido comprensible yo una cosa ". Resulta que de repente le diste a los bárbaros las llaves del reino.

Por lo tanto, al configurar este encabezado, le está diciendo al navegador que no haga nada como esto. Esto puede mitigar en gran medida los efectos de ciertos tipos de ataques. Aquí hay una breve descripción de algunas vulnerabilidades para los ataques de secuencias de comandos entre sitios.

Ahora veamos otro vector de ataque popular: SQL. Probablemente haya oído hablar de ataques llamados "inyección SQL" o ataque de inyección SQL. La esencia de estos ataques es usar la base de datos del sitio web. Para generar dinámicamente la página que se muestra al usuario, se emiten consultas de base de datos que se emiten a este servidor interno. Imagine que tiene una solicitud para seleccionar todos los valores de una tabla específica, donde el campo ID de usuario es igual a lo que se determina en Internet de una fuente potencialmente poco confiable.



Todos sabemos cómo terminará esta historia: terminará muy mal, no habrá sobrevivientes. Porque lo que proviene de una fuente no verificada puede causar muchos problemas. Alternativamente, puede darle a la cadena de identificación de usuario el siguiente valor: identificación de usuario = “0; BORRAR TABLA ".

Entonces, ¿qué pasará aquí? Básicamente, la base de datos del servidor dirá: "OK, estableceré la ID de usuario en cero, y luego ejecutaré el comando" eliminar tabla "". Y eso es todo, ¡ya está!

Dicen que hace un par de años apareció una cierta imagen viral. Algunas personas en Alemania instalaron placas en los automóviles, en las cuales se escribió 0; BORRAR TABLA. La idea era que las cámaras de carretera usaran OCR para reconocer su número y luego lo pusieran en la base de datos. En general, la gente del Volkswagen decidió explotar esta vulnerabilidad al colocar código malicioso en sus números.

No sé si esto funcionó porque suena gracioso. Pero me gustaría creer que esto es cierto. Así que repito nuevamente: la idea de desinfección es evitar la ejecución de contenido de fuentes no confiables en su sitio.



Por lo tanto, preste atención al hecho de que puede haber algunas cosas simples que no funcionan como deberían. Entonces, usted podría pensar: "bueno, ¿por qué no puedo simplemente poner otra cita al principio de la línea y una más al final para excluir la ejecución del código malicioso del atacante encerrado entre comillas triples"?

ID de usuario = '"+ ID de usuario +'"

Pero esto no funcionará, porque un atacante siempre puede simplemente poner comillas dentro de la cadena de ataque. Por lo tanto, en la mayoría de los casos, este "medio pirateo" no le brindará tanta seguridad como espera.

La solución aquí es que necesita cifrar cuidadosamente sus datos. Y una vez más, repito que cuando reciba información de una fuente poco confiable, no la inserte en el sistema en la forma en que se encuentra. Asegúrate de que no pueda saltar de la caja de arena si lo pones allí para realizar una explotación maliciosa.

Por ejemplo, desea insertar una función de escape para evitar el uso del operador de coma sin formato. Para hacer esto, muchos de los marcos web, como Django, tienen bibliotecas integradas que le permiten evitar consultas SQL para evitar que sucedan tales cosas. Estos marcos animan a los desarrolladores a nunca interactuar directamente con la base de datos. Por ejemplo, Django proporciona una interfaz de alto nivel que lo desinfecta.

Pero las personas siempre se preocupan por el rendimiento y, a veces, piensan que estos marcos web son demasiado lentos. Entonces, como verá pronto, la gente seguirá haciendo consultas SQL sin procesar, lo que puede generar problemas.

Pueden surgir problemas si el servidor web acepta nombres de ruta de imágenes no confiables. Imagine que en algún lugar de su servidor está haciendo algo similar: abra con “www / images /” + nombre de archivo, donde el nombre de archivo está representado por algo como ... / ... / ... / ... / etc / contraseña.



Es decir, le da la orden de abrir la imagen en esta dirección desde un archivo de usuario no confiable, que en realidad puede dañarlo gravemente. Por lo tanto, si desea utilizar un servidor web o un marco web, debería poder detectar estos caracteres peligrosos y evitarlos para evitar la ejecución de estos comandos no controlados.

Tomemos un descanso de discutir la desinfección de contenido y hablemos un poco sobre las cookies. Las cookies son una forma muy popular de administrar sesiones para vincular a un usuario a un determinado conjunto de recursos que existen en el lado del servidor. Muchos marcos como Django o Zoobar, que conocerá más adelante, en realidad colocan un identificador de sesión aleatorio dentro de las cookies. La idea es que este ID de sesión es un índice en algún tipo de tabla del lado del servidor:

tabla [ID de sesión] = información del usuario.

Es decir, el identificador de sesión es igual a cierta información del usuario. Como resultado, este ID de sesión y las cookies son piezas muy sensibles en su extensión. Muchos ataques incluyen el robo de cookies para obtener esta ID de sesión. Como discutimos en nuestra última conferencia, la misma política de la misma fuente de origen puede ayudarlo, en cierta medida, contra algunos de estos ataques de robo de cookies. Porque hay reglas basadas en la misma política de origen que impiden la modificación arbitraria de las cookies.

La sutileza es que no debe compartir un dominio o subdominio con alguien en quien no confía. Porque, como dijimos en la última conferencia, hay reglas que permiten que dos dominios o subdominios del mismo origen accedan a las cookies del otro. Y, por lo tanto, si confía en un dominio en el que no debe confiar, puede establecer directamente el identificador de sesión en estas cookies, a las que ambos tienen acceso. Esto permitirá que el atacante obligue al usuario a usar el identificador de sesión que elija el atacante.



Supongamos que un atacante establece una cookie de usuario de Gmail. Un usuario inicia sesión en Gmail y escribe algunas letras. Un atacante puede usar esta cookie, en particular, usar este identificador de sesión, descargar Gmail y luego acceder a Gmail como si fuera un usuario víctima. Por lo tanto, hay muchas sutilezas que puede hacer con estas cookies para administrar sus sesiones. .

, , ? , . ?

stateless cookie, « », - , , , .

, , , . , . , , . , , , , .

— MA — Message Authentication Codes, . , . HCK - m. , , K. , , . , , .



, . , stateless cookie, Amazon, , x3. - Amazon, AWS, . – K, – AWS, .



, AWS HTTP, .

, , , :

GET /photos/ cat; .jpg HTTP/1.1, - AWS:

HOST: — - — - — , , :

DATE: Mon, June 4, , , . , ID , , , .



? , 3- .

, String To Sign :

— HTTP, GET;
— MDS;
— , html jpg;
— ;
— , , .



, , HCK MAC. , . , . , . ?

, , , - . Amazon , stateless cookie, MD5 .

, , , cookie, . – , , .

, . , , “HCK, m”.



. GET /photos/ cat; .jpg HTTP/1.1 , , . , , . , ? : «, , , ».

56:15

Curso MIT "Seguridad de sistemas informáticos". 9: « Web-», 3


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?