He estado estudiando el protocolo Websocket ( RFC 6455 ). La sección 10.3 habla específicamente sobre el enmascaramiento de marcos, que evita el envenenamiento de caché de los servidores proxy http.
¿Cómo evita el enmascaramiento de cuadros el envenenamiento de caché? ¿Cómo se "envenena" un caché de proxies? ¿Por qué el enmascaramiento solo se aplica a los mensajes del cliente al servidor y no al revés?
¿Este ataque también se puede aplicar a métodos de sondeo largo (específicamente XHR)?
Eso es un montón de preguntas. Nos limitaremos al problema principal y la técnica de mitigación:
Existe la posibilidad de que mi proxy de almacenamiento en caché pueda examinar mi proxy o examinarlo de otra manera. Y hay una buena posibilidad de que pueda engañar al proxy si puedo obtener los datos correctos en mi solicitud y los datos deseados en la respuesta. La idea básica se demostró en un documento llamado Hablando contigo mismo por diversión y beneficio .
Como cliente atacante, lo que quiero hacer es enviar contenido al servidor que contiene una cadena de solicitud aparentemente válida:
... something ...
GET /jquery-latest.min.js HTTP/1.1
Host: code.jquery.com
...
... something that triggers the desired response from the server
El único requisito es que encuentres una manera de hacer que el servidor te envíe una cadena deseada, que normalmente no es demasiado difícil. Luego, el servidor predeciblemente devuelve la respuesta deseada:
HTTP/1.1 200 OK
content-type: text/javascript
... my trojaned javascript file
En lo que respecta al servidor y al cliente, solo estamos pasando cadenas de un lado a otro. Sin motivo real de preocupación, sin daño, sin posible vector para la explotación.
Pero un proxy que observa el tráfico vería lo que se parece mucho a una solicitud HTTP, y luego se parece mucho a una respuesta HTTP. Y si el proxy es lo suficientemente ingenuo (y muchos lo son), actualizará su caché en consecuencia, de modo que la próxima vez que alguien solicite enlace a través del proxy, obtendrán mi versión troyana en lugar del código real entregado por CDN.
Para protegerse de esto, el tráfico en una dirección (en este caso, de cliente a servidor) está ligeramente codificado. No tiene que ser criptográficamente seguro ya que no le importa si alguien puede decodificarlo. Solo debe asegurarse de que el cliente no pueda predecir qué cadena transmitirá a través de la red. Y como no puede predecir el tráfico de su red, no puede usar este mecanismo para activar un servidor proxy para actualizar su caché.
El proxy solo verá un evento almacenable en caché si TANTO la solicitud Y la respuesta contienen lo que parece ser el tráfico HTTP. Por lo tanto, solo es necesario unir una dirección.
Esto no se aplica a XHR, ya que las solicitudes XHR son solicitudes HTTP "normales" y son bien entendidas por los proxies.
¿Cómo evita el enmascaramiento de cuadros el envenenamiento de caché?
La idea es evitar que el contenido del marco se interprete como una solicitud / respuesta HTTP en curso mediante la manipulación de los datos del marco.
En realidad, creo que esto es totalmente inútil.
Supongamos que he escrito un cliente WebSocket simple (en realidad es cierto), como remitente del marco, puedo elegir la palabra de enmascaramiento. Todo lo que tengo que hacer es crear un marco de datos aleatorios con algunos encabezados HTTP en el medio y aplicar el algoritmo de enmascaramiento xor. Luego, envíe ese marco en mi WebSocket utilizando la misma máscara, el enmascaramiento xor del WebSocket simplemente hará que las partes HTTP sean texto plano en el cable.
Tuyo, TonyWilk
Lea otras preguntas en las etiquetas websocket