blog

La inyección HTML es un tipo de vulnerabilidad de inyección producida cuando un usuario es capaz de controlar un punto de entrada, además de ser capaz de inyectar código HTML arbitrario en una página web vulnerable. Esta vulnerabilidad puede tener muchas consecuencias, como revelar cookies de sesión para un usuario, las cuales podrían utilizarse para suplantar la identidad de la víctima o, de forma más general, permitir al atacante modificar el contenido de la página visualizada por las víctimas.

Esta vulnerabilidad ocurre cuando la entrada del usuario no está correctamente limpiada, y la salida no está codificada. Una inyección permite al atacante enviar una página HTML maliciosa hacia una víctima. El navegador atacado no podrá distinguir (confiar) las partes legítimas de las partes maliciosas de la página y, en consecuencia, analizará y ejecutará toda la página en el contexto de la víctima.

Existe una amplia diversidad de métodos y atributos factibles de utilizarse para renderizar contenido HTML. Si estos métodos se proporcionan con una entrada no fiable, entonces existe un alto riesgo para una vulnerabilidad de inyección HTML. Por ejemplo; se puede inyectar código HTML malicioso a través del método JavaScript innerHTML, el cual se utiliza para representar código HTML introducido por el usuario. Si las cadenas no se limpian correctamente, el método puede permitir la inyección de HTML. Una función de JavaScript factible de utilizarse con este fin es document.write().

La vulnerabilidad puede ser identificada y explotada utilizando interceptando la petición utilizando el método POST. Se ingresan datos en el formulario, para luego enviarlos hacia la aplicación.

Se define el modo interrupción en Zed Attack Proxy.

El modo interrupción en Zed Attack Proxy, permite editar los datos enviados a través del formulario.

Se cambia el valor del parámetro de nombre “firstname” a lo siguiente:

%3Chtml%3E%3Cbody%3E%3Cimg+src%3D%27aaa%27+onerror%3Dalert%28%27ABC%27%29%3B%3E%3C%2Fbody%3E%3C%2Fhtml%3E


Luego de realizada la modificación se procede a enviar la petición a través de Zed Attack Proxy.

Se ha identificado y explotado exitosamente la inyección HTML utilizando el método POST.

El propósito de esta prueba es identificar los puntos de inyección, además de evaluar la severidad del contenido inyectado.

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…
https://www.zaproxy.org/
https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
https://developer.mozilla.org/en-US/docs/Web/API/Document/write

La inyección HTML es un tipo de vulnerabilidad de inyección producida cuando un usuario es capaz de controlar un punto de entrada, además de ser capaz de inyectar código HTML arbitrario en una página web vulnerable. Esta vulnerabilidad puede tener muchas consecuencias, como revelar cookies de sesión para un usuario, las cuales podrían utilizarse para suplantar la identidad de la víctima o, de forma más general, permitir al atacante modificar el contenido de la página visualizada por las víctimas.

Esta vulnerabilidad ocurre cuando la entrada del usuario no está correctamente limpiada, y la salida no está codificada. Una inyección permite al atacante enviar una página HTML maliciosa hacia una víctima. El navegador atacado no podrá distinguir (confiar) las partes legítimas de las partes maliciosas de la página y, en consecuencia, analizará y ejecutará toda la página en el contexto de la víctima.

Existe una amplia diversidad de métodos y atributos factibles de utilizarse para renderizar contenido HTML. Si estos métodos se proporcionan con una entrada no fiable, entonces existe un alto riesgo para una vulnerabilidad de inyección HTML. Por ejemplo; se puede inyectar código HTML malicioso a través del método JavaScript innerHTML, el cual se utiliza para representar código HTML introducido por el usuario. Si las cadenas no se limpian correctamente, el método puede permitir la inyección de HTML. Una función de JavaScript factible de utilizarse con este fin es document.write().

La vulnerabilidad puede ser identificada y explotada utilizando una entrada como:

http:// 192. 168.0 .12/bWAPP/htmli_get.php?firstname=%3Chtml%3E%3Cbody%3E%3Cimg+src%3D%27aaa%27+onerror%3Dalert%28%27ABC%27%29%3B%3E%3C%2Fbody%3E%3C%2Fhtml%3E&lastname=perez&form=submit


La entrada añade (inyecta) código HTML en el parámetro “firstname” hacia la página, la cual ejecutará el código insertado por el usuario malicioso en el contexto HTML.

El propósito de esta prueba es identificar los puntos de inyección, además de evaluar la severidad del contenido inyectado.

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…
https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
https://developer.mozilla.org/en-US/docs/Web/API/Document/write

¿Dónde encaja esta especificación?

Esta especificación define una gran parte de la plataforma web con mucho detalle. Su lugar en la pila de especificaciones de la plataforma web en relación con otras especificaciones, se puede resumir mejor como se muestra en la imagen.

¿Esto es HTML5?

En resumen: Sí.

Siendo más extenso: el término "HTML5" se usa ampliamente como palabra de moda para referirse a las tecnologías web modernas, muchas de las cuales (aunque no todas) se desarrollan en WHATWG. Este documento es uno de ellos; otros están disponibles en la descripción general de los estándares WHATWG, cuyo sitio web se detalla en la parte final de la presenta publicación.

Antecedentes

HTML es el lenguaje de marcado central para la World Wide Web. Originalmente HTML se diseñó principalmente como un lenguaje para describir de manera semántica documentos científicos. Su diseño general sin embargo ha permitido su adaptación, en los años subsecuentes, para describir un número de otros tipos de documentos e incluso aplicaciones.

Alcance

Esta especificación se limita a proporcionar un lenguaje de marcado a nivel semántico, y APIs para secuencias de comandos a nivel semántico asociadas para crear páginas accesibles en la web, abarcando desde documentos estáticos hasta aplicaciones dinámicas.

El alcance de esta especificación no incluye proporcionar mecanismos para la personalización de la presentación específica de los medios (aunque las reglas predeterminadas para representación en los navegadores web se incluyen al final de esta especificación, además varios mecanismos para conectarse a CSS se proporcionan como parte del lenguaje).

El alcance de esta especificación no es describir un sistema operativo completo. En particular, el software para configuración de hardware, las herramientas para manipulación de imágenes y las aplicaciones esperadas los usuarios usen diariamente con estaciones de trabajo de alta gama, están fuera del alcance. En términos de aplicaciones, esta especificación está dirigida específicamente hacia las aplicaciones esperadas los usuarios utilicen de forma ocasional o regular, pero desde diferentes ubicaciones, con bajos requisitos de CPU. Ejemplos de tales aplicaciones incluyen sistemas para compra en línea, sistemas para búsqueda, juegos (especialmente juegos en línea multijugador), guías telefónicas públicas o libretas de direcciones, software para comunicaciones (clientes de correo electrónico, clientes de mensajería instantánea, software de discusión), software de edición de documentos, etc.

Notas de Diseño

Debe admitirse muchos aspectos de HTML parecen en primera instancia absurdos e inconsistentes.

HTML, sus API DOM de soporte, así como muchas de sus tecnologías de soporte, han sido desarrollados durante un período de varias décadas por una amplia gama de personas con diferentes prioridades, lo cual en muchos casos no sabían de la existencia de los demás.

Por lo tanto las características han surgido desde muchas fuentes, y no siempre se han diseñado de manera especialmente consistente. Además, debido a las características únicas de la web, los errores de implementación frecuentemente se han convertido en estándares de facto, y ahora de-facto, pues el contenido frecuentemente se escribe involuntariamente, de manera tal depende de ellos antes de puedan ser corregidos.

A pesar de todo esto, se han realizado esfuerzos para adherirse a ciertas metas de diseño. Los cuales se describen en las diferentes secciones del estándar.

Fuentes:

https://html.spec.whatwg.org/
https://spec.whatwg.org/

IndexedDB es una API de bajo nivel para el almacenamiento en lado del cliente de cantidades significativas de datos estructurados, incluyendo archivos/blobs. Esta API utiliza índices para permitir búsquedas de alto rendimiento en estos datos. Mientras el almacenamiento web (Web Storage) es útil para almacenar pequeñas cantidades de datos, no lo es tanto para almacenar grandes cantidades de datos estructurados. IndexedDB ofrece una solución.

Conceptos clave y uso

IndexedDB es un sistema para base de datos transaccional, como un RDBMS basado en SQL. Sin embargo a diferencia de los RDBMS basados en SQL, los cuales utilizan tablas de columnas fijas, IndexedDB es una base de datos orientada a objetos basada en JavaScript. IndexedDB permite almacenar y recuperar objetos indexados con una clave; se puede almacenar cualquier objeto compatible con el algoritmo de clonado estructurado. Es necesario especificar el esquema de la base de datos, abrir una conexión con esta, y a continuación, recuperar y actualizar los datos dentro de una serie de transacciones.

Sincrónico y Asincrónico

Las operaciones realizadas con IndexedDB se realizan de forma asíncrona, para no bloquear las aplicaciones.

Límites de almacenamiento y criterios de desalojo

Existen varias tecnologías web las cuales almacenan datos de un tipo u otro en el lado del cliente (es decir en su disco local). Se habla sobre todo de IndexedDB. El proceso mediante el cual el navegador calcula cuanto espacio debe asignar al almacenamiento de datos web, además aquello lo cual debe eliminar cuando se alcanza ese límite no es sencillo, y difiere de un navegador a otro. Límites de almacenamiento del navegador y criterios de desalojo intentan explicar cómo funciona esto, al menos en el caso de Firefox.

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_…

El Sistema Común para Puntuación de Vulnerabilidades (CVSS) captura las principales características técnicas sobre las vulnerabilidades de software, hardware y firmware. Sus resultados incluyen puntuaciones numéricas indicando la severidad de una vulnerabilidad en relación con otras vulnerabilidades.

CVSS se compone de tres grupos de métricas: Base, Temporal y Ambiental. La puntuación base refleja la gravedad de una vulnerabilidad acorde a sus características intrínsecas, las cuales son constantes a lo largo del tiempo, además suponen el peor caso de impacto razonable en diferentes entornos desplegados. Las métricas temporales ajustan la gravedad base de una vulnerabilidad a través de factores cambiantes con el tiempo, como la disponibilidad de código para explotación. Las métricas ambientales ajustan la severidad base y temporal hacia un entorno de cómputo específico. Estos consideran factores como la presencia de mitigaciones en el entorno.

Las puntuaciones Base son usualmente elaboradas por la organización manteniendo el producto vulnerable, o por un tercero quien realiza la puntuación en su nombre. Es habitual sólo se publiquen las métricas de Base, pues éstas no cambian con el tiempo y son comunes hacia todos los entornos. Los consumidores de CVSS deben complementar la puntuación Base con puntuaciones Temporales y Ambientales específicas hacia su uso del producto vulnerable, para obtener una severidad más precisa para su entorno organizacional. Los consumidores pueden utilizar la información del CVSS como una entrada hacia un proceso para la gestión de vulnerabilidades en la organización, el cual también considere factores no formando parte del CVSS, con el propósito de clasificar las amenazas hacia su infraestructura tecnológica, y tomar decisiones fundamentadas para remediar. Tales factores pueden incluir: número de clientes en una línea de productos, pérdidas monetarias debidas a una breca, vidas o propiedades amenazadas, o sentimiento público sobre vulnerabilidades altamente publicitadas. Estos factores quedan fuera del ámbito del CVSS.

Los beneficios del CVSS incluyen la provisión de una metodología estandarizada para la puntuación de vulnerabilidades, independiente del proveedor y de la plataforma. Se trata de un marco de trabajo abierto, el cual proporciona transparencia a las características individuales y a la metodología utilizada para obtener una puntuación.

Fuente:

https://www.first.org/cvss/v3.1/specification-document

¿Qué es el GDPR? La nueva ley europea para privacidad y seguridad de datos incluye cientos de páginas sobre los nuevos requisitos para las organizaciones de todo el mundo. Esta descripción general del GDPR ayudará a entender la ley, además de determinar cuales partes de la misma afectan.

El Reglamento General para Protección de Datos (GDRP), es la ley para privacidad y seguridad más estricta del mundo. Aunque fue redactado y aprobado por la Unión Europea (UE), impone obligaciones para las organizaciones, siempre se dirijan o recopilen datos relacionados con personas de la UE. El reglamento entró en vigor el 25 de mayo de 2018. GDPR impone duras multas a quienes infrinjan sus normas de privacidad y seguridad, con sanciones alcanzando las decenas de millones de euros.

Con el GDPR, Europa señala su firme postura sobre la privacidad y seguridad de los datos en un momento en el cual cada vez más personas confían sus datos personales hacia servicios en la nube, siendo las infracciones un hecho cotidiano. El reglamento en sí es amplio, de gran alcance, y poco específico, lo cual hace el cumplimiento de GDPR sea una perspectiva desalentadora, especialmente para las pequeñas y medianas empresas (PYME).

Se ha creado su sitio web oficial para servir de recurso a los propietarios y gestores de PYME, para aborden los retos específicos a los cuales se enfrentarán. Aunque no sustituye al asesoramiento jurídico, puede ayudar a comprender dónde centrar esfuerzos de cumplimiento del GDRP. También se ofrecen consejos sobre herramientas de privacidad y como mitigar los riesgos. Conforme se vaya interpretando el GDRP, se mantendrá informado sobre la evolución de las mejores prácticas.

El Reglamento General para Protección de Datos es una ley de la Unión Europea implementada el 25 de mayo de 2018, para exigir a las organizaciones salvaguardar los datos personales y defender los derechos de privacidad de cualquier persona en el territorio de la UE. El Reglamento incluye siete principios de protección de datos los cuales deben aplicarse, además de ocho derechos de privacidad los cuales deben facilitarse. También faculta a las autoridades de protección de datos de los Estados miembros para hacer cumplir el GDRP con sanciones y multas. El GDRP sustituye a la Directiva de Protección de Datos de año 1995, el cual creaba un mosaico de leyes para la protección de datos en cada país. El GDRP aprobado en el Parlamento Europeo por abrumadora mayoría, unifica la UE en un régimen único para protección de datos.

Fuente:

https://gdpr.eu/what-is-gdpr/
https://gdpr.eu/faq/

Este documento ha sido preparado para proporcionar los requisitos para establecer, implementar, mantener, y mejorar continuamente un sistema para la gestión en seguridad de la información. La adopción de un sistema para la gestión en seguridad de la información, es una decisión estratégica para una organización. El establecimiento e implementación del sistema para la gestión en seguridad de la información en una organización, está influenciado por las necesidades y metas de la organización, los requisitos de seguridad, los procesos organizativos utilizados, además del tamaño y estructura de la organización. Se espera todos estos factores de influencia cambien con el tiempo.

El sistema para la gestión en seguridad de la información preserva la confidencialidad, integridad y disponibilidad de la información, aplicando un proceso para la gestión de riesgos, y proporciona confianza hacia las partes interesadas de los riesgos son gestionados adecuadamente.

Es importante el sistema para la gestión en seguridad de la información forme parte y esté integrado con los procesos y estructura para la gestión general de la organización, además la seguridad de la información se tenga consideración para el diseño de los procesos, los sistemas de información, y los controles. Se espera la implantación para un sistema de gestión en seguridad de la información se adapte a las necesidades de la organización.

Este documento puede ser utilizado por partes internas y externas, para evaluar la capacidad de la organización en cumplir con los requisitos en seguridad de la información de la propia organización.

El orden en el cual se presentan los requisitos en este documento no reflejan su importancia ni implica el orden en el cual deben aplicarse. Los elementos de la lista se enumeran únicamente con fines de referencia.

ISO/IEC 27000 describe la visión general y el vocabulario para los sistemas de gestión en seguridad de la información, haciendo referencia hacia la familia de normas para sistemas de gestión en seguridad de la información (incluyendo ISO/IEC 27003, ISO/IEC 27004 e ISO/IEC 27005), con términos y definiciones relacionados.

Fuentes:

https://www.iso.org/standard/82875.html
https://www.iso.org/obp/ui/#iso:std:iso-iec:27003:en
https://www.iso.org/obp/ui/#iso:std:iso-iec:27003:en

A finales de la década de 1990, muchos sitios web se caracterizaban por ser delanteras HTML hacia bases de datos. Los sitios web modernos presumen de manejar conjuntos de datos del tamaño de petabytes, lo cual supone un crecimiento en órdenes de magnitud superior comparado con la década anterior. No hay indicios de este almacenamiento de datos centrado en la red disminuya, teniendo en consideración la "computación en la nube" y el "software como servicio".

Esto no significa los desarrolladores web quieran mantenerlo todo en una base de datos dirigida por un servidor web. Existen muchos beneficios en lo referente a la descarga del almacenamiento de datos hacia el navegador; desde el ancho de banda hasta el rendimiento y los costes de almacenamiento. La cookie HTTP ha sido siempre el caballo de batalla del almacenamiento en el navegador. Sin embargo las cookies tienen límites de cantidad (20 cookies por dominio), tamaño (4 KB por cookie) y seguridad (un atributo de ruta inútil 2 ); los cuales han sido acordados por los fabricantes de navegadores en principio y no por estándar.

El propósito del Almacenamiento Web (Web Storage) es ofrecer un mecanismo para los desarrolladores web puedan almacenar grandes cantidades de datos en el navegador, utilizando una API estándar para todos los navegadores. Las principales características de Web Storage atestiguan su ascendencia en la cookie HTTP: los datos se almacenan como pares clave/valor, y los objetos de Web Storage pueden marcarse como sessionStorage o localStorage (similar a las cookies de sesión y persistentes).

Las claves y los valores de un objeto de almacenamiento son siempre cadenas de JavaScript. Un objeto de almacenamiento de sesión está vinculado hacia un contexto de navegación. Por ejemplo, dos pestañas diferentes del navegador tendrán objetos sessionStorage únicos. Los cambios en una no afectarán a la otra. El contenido de un objeto localStorage será accesible a todas las pestañas del navegador; la modificación de un par clave/valor de una pestaña afectará al almacenamiento de cada pestaña. En todos los casos el acceso está restringido por la Política del Mismo Origen.

Un aspecto importante de la seguridad del almacenamiento web es los datos son visibles y modificables por el usuario.

El siguiente código demuestra un patrón común para enumerar las claves de un objeto de almacenamiento a través de un bucle.

var clave;
for (var i = 0, len = localStorage.length; i < len; i++){
key = localStorage.key(i);
console.log(localStorage.getItem(key));
}

Por último, tener presente las siguientes consideraciones en seguridad. La atención aquí se centra en la forma en la cual la tecnología HTML5 es utilizada por una aplicación web, en lugar de las vulnerabilidades específicas en la implementación o el diseño de la tecnología en el navegador.

• Preferir la purga oportunista de datos. Determinar un tiempo de vida apropiado para los datos sensibles. El hecho de un navegador se cierre no significa se eliminen los datos de un objeto sessionStorage. En su lugar, la aplicación podría eliminar los datos después de un tiempo (para ser ejecutado cuando el navegador está activo, por supuesto) o podría ser eliminado en un evento beforeunload (o onclose si cualquiera de los dos eventos es desencadenado de forma fiable por el navegador).
• Recuerde los datos colocados en un objeto de almacenamiento tienen la misma exposición comparado al uso de una cookie. Su seguridad depende de la Política de Mismo Origen del navegador, el nivel de parches del navegador, los plugins, y el sistema operativo subyacente. Encriptar los datos es el objeto de almacenamiento tiene la misma seguridad a encriptar la cookie. La colocación de la clave para la desencriptación en el objeto de almacenamiento (o su envío hacia el navegador) anula la seguridad de los datos cifrados.
• Considerar la privacidad y la sensibilidad asociadas con los datos colocados en un objeto de almacenamiento. La capacidad de almacenar más datos no debería traducirse en la capacidad de almacenar más datos sensibles.
• Prepararse para el compromiso. Un ataque de inyección html ejecutándose dentro del mismo origen del objeto de almacenamiento, podrá enumerar y exfiltrar los datos sin restricciones. Tener esto en consideración cuando se seleccionen los tipos de datos almacenados en el navegador.
• HTML5 no hace mágicamente el sitio sea más seguro. Características como <iframe> sandboxing y la cabecera Origin son buenas maneras de mejorar el diseño de seguridad. Sin embargo estas llamadas siguen siendo inefectivas por proxies mal configurados eliminando las cabeceras, navegadores antiguos no soportan estas características, o una pobre validación de datos permite el contenido malicioso se infiltre en una página web.

Fuentes:

https://www.w3schools.com/html/html5_webstorage.asp
https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

Negación de servicio (DoS). Los navegadores web limitan el número de conexiones concurrentes hechos hacia un Origen (la página de una aplicación web puede estar constituida de recursos desde varios Orígenes). Este límite suele ser de cuatro o seis para equilibrar la capacidad de respuesta percibida por el navegador con la sobrecarga de conexión impuesta al servidor. Las conexiones WebSockets no tienen las mismas restricciones por origen. Esto no significa se haya ignorado la posibilidad de utilizar WebSockets para hacer DoS hacia un sitio. En cambio el protocolo define comportamientos los cuales deben seguir los navegadores y los servidores. Por lo tanto el diseño del protocolo está destinado a minimizar esta preocupación para los propietarios de los sitios, pero eso no significa los errores de implementación permitendo los ataques DoS aparecerán en los navegadores.

Por ejemplo, una carga útil de inyección HTML podría entregar código JavaScript para crear docenas de conexiones WebSockets desde los navegadores de las víctimas hacia el sitio web. La mera presencia de WebSockets sobre un sitio no es una vulnerabilidad. Este ejemplo describe el uso de WebSockets para agravar otro exploit (cross-site scripting) de forma tal el sitio quede inutilizable.

Protocolos en túnel. La tunelización de protocolos binarios (es decir datos no textuales) a través de WebSockets es una ventaja convincente de esta API. Aunque el protocolo WebSocket puede estar implementado de forma segura, el protocolo tunelizado sobre este puede no estarlo. Los desarrolladores web deben aplicar los mismos principios para la validación de entradas, autenticación, autorización, etc., para la gestión del lado del servidor de los datos llegando a través de una conexión WebSocket. El uso de una conexión wss: // desde un navegador actualizado no tiene relación con los potenciales desbordamientos de búfer para el código en el lado del servidor manejando el chat, la transmisión de imágenes, o cualquier otro elemento enviado a través de la conexión.

Este problema no es específico de los protocolos binarios, pero se destacan aquí porque tienden a ser más difíciles de inspeccionar. Es mucho más fácil para los desarrolladores leer y revisar los datos de texto como las peticiones HTTP y los datos POST, comparado con inspeccionar los flujos de datos binarios. Esto último requiere herramientas adicionales para inspeccionar y verificar. Tener en consideración este problema de seguridad está relacionado con la forma en la cual se utilizan los WebSockets, no una inseguridad en el propio protocolo WebSocket.

Servidor Retransmisor no Fiable. El endpoint ws: // o wss: // podría retransmitir datos desde el navegador hacia un Origen arbitrario, violando las expectativas de privacidad o los controles de seguridad. Por un lado, una conexión a wss: //web. site/ podría enviar datos desde el navegador hacia un servidor VNC, en una red interna normalmente inalcanzable desde la Internet pública, como si fuera una conexión VPN. Este uso no viola ni el espíritu ni la especificación de WebSockets. En otro escenario, una conexión WebSocket podría ser utilizada para retransmitir mensajes desde el navegador hacia un servidor IRC. De nuevo, esto podría ser un uso inteligente de los WebSockets. Sin embargo el retransmisor IRC podría vigilar los mensajes pasados a través de este, incluso retransmitir los mensajes hacia diferentes destinos según se requiera. En otro caso, una conexión WebSocket podría ofrecer un servicio de inicio de sesión único a través de una conexión encriptada wss: //, pero proxear datos como nombre de usuario y contraseña a través de canales no encriptados como HTTP.

No hay más o menos razón para confiar en un servidor ejecutando un servicio WebSocket comparado con uno ejecutando HTTP normal. Un servidor malicioso atacará los datos de un usuario independientemente de la seguridad correspondiente a la conexión o al navegador. Los WebSockets proporcionan un medio para introducir en el navegador protocolos útiles diferentes a HTTP, con posibilidades yendo desde la mensajería de texto hasta la transferencia de vídeo. Sin embargo la capacidad de los WebSockets para transferir datos arbitrarios revivirá antiguas estafas en las cuales los sitios maliciosos actúan como front-ends destinos de medios sociales, bancarios, etc. Los WebSockets serán simplemente otra herramienta la cual permitirá estos esquemas. Igual se debe advertir a los usuarios de no confíen demasiado en la "seguridad" de los certificados SSL, se debe tener cuidado con el tipo de datos transmitiendose a través de las conexiones WebSocket. Los desarrolladores de navegadores y los propietarios de sitios web no pueden hacer mucho para bloquear el phishing, y otros ataques similares de ingeniería social.

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Appl…
https://portswigger.net/web-security/websockets

Los navegadores exponen la mínima API necesaria para JavaScript interactúe con los WebSockets, utilizando eventos como onopen, onerror, onclose, y onmessage, además de métodos como close y send. Los mecanismos para transferir los datos en crudo para las llamadas desde JavaScript hacia el tráfico de red se manejan en lo más profundo del código correspondiente al navegador. La principal preocupación desde la perspectiva de la seguridad en las aplicaciones web, es como un sitio web utiliza los WebSockets: ¿Sigue validando los datos para evitar la inyección SQL o los ataques XSS? ¿Realiza la aplicación correctamente la autenticación y autorización para los usuarios accedan hacia páginas uttilizando WebSockets?

No obstante, sigue siendo interesante tener una idea básica de cómo funcionan los WebSockets en la red. En términos de WebSockets, como la tramas de datos envían datos. La referencia completa está en la sección cinco del RFC 6455. Aquí se destacan algunos aspectos interesantes.

000002AB 81 9b 82 6e f6 68 cb 1d d6 1c ea 0b 84 0d a2 0f ...n.h..........
000002BB 98 11 e0 01 92 11 a2 01 83 1c a2 1a 9e 0d f0 0b ................
000002CB c9.

La anterior trama de datos fue enviada por el navegador. El primer byte, 0×81, tiene dos mitades importantes. El valor, 0×81, representa en binario como 10000001b. El primer bit representa la bandera FIN (mensaje terminado), puesta a 1. Los tres bits siguientes no se utilizan actualmente y deben ser siempre 0. Los cuatro bits finales pueden ser uno de varios opcodes. La siguiente imagen enumera los posibles opcodes.

Observando el primer byte del ejemplo, 0×81, se determina se trata de un único fragmento (el bit FIN está activado) contiendo texto (opcode 0×01). El siguiente byte, 0x1b, indica la longitud del mensaje, 27 caracteres. Este tipo de campo de longitud prefijada es común a muchos protocolos. Si se saliera de la seguridad en las aplicaciones web para sumergirse en las pruebas de protocolo, una de las primeras pruebas sería modificar la longitud de la trama de datos para ver como reacciona el servidor a los excesos y rebasamientos de tamaño. Definir valores de gran tamaño para mensajes pequeños también podría llevar hacia un DoS, si el servidor reservase alegremente la cantidad de memoria solicitada antes de percatarse el mensaje real no era ni de lejos tan grande.

00000150 81 1b 49 73 20 74 68 65 72 65 20 61 6e 79 62 6f ..Is there anybo
00000160 64 79 20 6f 75 74 20 74 68 65 72 65 3f dy out t there?

Finalmente se tiene una trama de datos de cierre. El bit FIN está definido y el opcode 0×08 le indica al extremo remoto termine la conexión.

000002CC 88 82 04 4c 3a 56 07 a4 ...L:V..

Las tramas de datos en WebSockets tienen otros tipos de composición. Sin embargo estos aspectos están en gran medida fuera del alcance de las pruebas contra las aplicaciones web, pues son los desarrolladores de los navegadores y los desarrolladores de los servidores web quienes se encargan de esto. Aun así un proyecto paralelo para probar una implementación particular de WebSockets podría ser divertido. He aquí algunos consejos finales sobre las áreas a revisar en la capa de protocolo:

• Establecer valores de longitud no válidos;
• Establecer banderas no utilizadas;
• Banderas de enmascaramiento y claves de enmascaramiento no coincidentes;
• Respuesta de mensajes;
• Envío de tramas fuera de orden o fragmentos superpuestos;
• Fijación de secuencias UTF-8 no válidas en mensajes de texto (opcode 0×01).

La especificación define cómo deben reaccionar los clientes y servidores ante situaciones de error, pero no hay razón para esperar un código libre de errores en los navegadores o servidores. Esta es la diferencia entre seguridad de diseño y seguridad de implementación.

Fuentes:

https://www.rfc-editor.org/rfc/rfc6455
https://www.rfc-editor.org/rfc/rfc6455#section-5