Já parou para pensar em WebSockets?

Por Caio Fook.

Este blog post é o resumo da minha pesquisa do primeiro ciclo de estágio no time de consultoria técnica da Tempest. A pesquisa se baseou em um estudo do protocolo WebSocket, com enfoque nas falhas de segurança que poderiam impactar suas implementações em aplicações web.

Porém, como discutir a segurança de um protocolo sem primeiro entendê-lo? Por isso, busco agregar nesta leitura uma visão geral sobre o seu funcionamento e, em sequência, poderemos nos aprofundar nas questões de segurança propriamente ditas.  

Vale notar que a pesquisa foi conduzida através da leitura de documentações técnicas, artigos e de testes em ambiente de laboratório, cujos links estão disponíveis ao final do texto. 

Boa leitura!

A utilização do protocolo WebSocket na web

O protocolo WebSocket nasceu em 2008 como rascunho, parte da especificação HTML5, e tornou-se padrão em sua versão 13, introduzida em 2011 com a publicação da RFC 6455.

O objetivo por trás deste protocolo era possibilitar uma comunicação mais próxima do tempo real, a fim de otimizar ou até viabilizar aplicações web que necessitassem de comunicação “instantânea” entre clientes e servidores. Ou seja, aplicações web com funcionalidades de chat, jogos, notícias e atualizações em tempo real, por exemplo. 

De 2011 para cá, contudo, a web passou por transformações, com o advento do HTTP/2, HTTP/3 e outras tecnologias, o WebSocket hoje não é a única tecnologia apta a estabelecer comunicação “bilateral e em tempo real”.

Por exemplo, com o HTTP/2 temos a compressão de cabeçalhos e ideia de a multiplexação dos dados sendo realizada pelo próprio HTTP/2, viabilizando um canal de comunicação persistente e formado por múltiplas streams de dados. Já no HTTP/3, temos uma comunicação feita através do protocolo de transporte QUIC (baseado no UDP), que já agrega multiplexação ativa.

A evolução da comunicação web também trouxe tecnologias como HTTP/2 Server-Sent Events, gRPC e WebRTC, possibilitando comunicação em tempo real ideal para certos cenários, o que levantou discussões sobre o futuro do WebSocket. Contudo, o WebSocket ainda é utilizado por diversas aplicações modernas, desde chats a aplicações de mercado de valores, possuindo até especificações para sua utilização em conjunto com as versões 2 e 3 do HTTP.

Veremos na seção seguinte que a conexão WebSocket deve ser iniciada a partir do HTTP. Nesse ponto, sua inicialização e aspectos da conexão variam significativamente entre HTTP/1.1, HTTP/2 e HTTP/3. As diferenças residem na ideia de que WebSocket foi concebido para utilizar a conexão TCP que estava em uso pelo HTTP/1.1. Porém, no caso das versões HTTP/2 e HTTP/3, o WebSocket assume uma HTTP stream da requisição HTTP, ao invés de substituí-la. 

Para entender o funcionamento do WebSocket, iremos considerar a sua implementação via HTTP/1.1, que continua sendo a mais utilizada. Caso você queira se aprofundar em mais detalhes sobre a inicialização de uma conexão WebSocket através de HTTP/2 ou HTTP/3, recomendo a leitura das RFCs 8441 e 9220. 

Aspectos gerais e funcionamento

Como sabemos, o HTTP, protocolo de aplicação central da comunicação web, é baseado no modelo requisição-resposta, que não foi criado inicialmente para comunicação em tempo real.  

No HTTP/1.1, cada par requisição-resposta utiliza, em seu funcionamento padrão, uma única conexão TCP temporária e o servidor não envia mensagens por iniciativa própria. 

O WebSocket seria a opção para solucionar esta “lacuna”, utilizando uma única conexão TCP persistente como canal bidirecional entre cliente e servidor trocarem mensagens, como ilustrado abaixo:

Imagem 1: Comparação HTTP x WebSocket – Fonte: Tempest

Embora fosse possível implementar requisição HTTP/1.1 com reutilização de conexões TCP e técnicas como pipelining, pooling e HTTP streaming para flexibilizar o cenário ilustrado acima, estas técnicas não eram capazes de promover uma comunicação “em tempo real” tão fluida quanto aquela proposta pelo protocolo WebSocket, que foi concebido para, por padrão, ter uma estrutura de dados leve (WebSocket frame) montada sobre uma conexão TCP persistente. 

Estabelecimento da conexão WebSocket

Uma conexão WebSocket deve ser iniciada pelo WebSocket client, que daqui para frente simplificamos chamando-o simplesmente de navegador. 

O mecanismo de inicialização é chamado de WebSocket handshake, iniciado pelo navegador por meio de uma requisição de upgrade. Esta consiste em uma requisição HTTP específica que carrega os cabeçalhos Upgrade e Connection e informa ao servidor que o navegador deseja se comunicar via WebSocket. 

Abaixo, vamos analisar uma requisição HTTP/1.1 de upgrade e a resposta do servidor:

Imagem 2: WebSocket Handshake – Fonte: Tempest

Na imagem acima, temos em negrito os elementos que sempre constarão nas mensagens do handshake. Os elementos acinzentados em colchetes são opcionais, conforme especificado na RFC 6455. 

Para construir a upgrade request, o navegador utilizará a WebSocket API, biblioteca padrão em javascript que contém os métodos e manipuladores de evento necessários para estabelecer, utilizar e encerrar conexões WebSocket:

Imagem 3: WebSocket API, métodos e eventos – Fonte: Tempest

É através desta API que o navegador envia e recebe mensagens WebSocket, sendo capaz de capturar o conteúdo de mensagem WebSocket e incluí-lo na página HTML.

Por exemplo, o script abaixo constrói e envia uma requisição de upgrade e, caso o servidor conclua o handshake, envia na conexão uma mensagem com o conteúdo “Conectado!”:

Imagem 4: Exemplo de script para inicializar o processo de um WebSocket handshake – Fonte: Tempest

Do lado do back-end, teremos uma implementação de servidor WebSocket, que utilizará uma biblioteca apropriada para munir o back-end de métodos para gerenciar as conexões ativas, interpretar mensagens dos navegadores, além de construir e enviar seus próprios WebSocket frames.

Antes de falarmos sobre WebSocket frames, vale a pena ilustrarmos a modificação que ocorre a nível de conexão quando um WebSocket handshake é concluído. Podemos ver na imagem abaixo, que a conexão TCP, antes utilizada na troca das mensagens HTTP, é reaproveitada para a conexão WebSocket, como ilustrado abaixo:

Imagem 5: Conexão WebSocket iniciada via HTTP/1.1 com TLS – Fonte: Tempest

É importante notar que esta conexão é estabelecida de forma diferente caso sejam utilizados HTTP/2 ou HTTP/3, uma vez que nestes casos o WebSocket não utilizará diretamente a conexão da camada de transporte (TCP), mas sim um stream HTTP, sendo assim multiplexado dentro do HTTP ao invés de “substituí-lo”. 

Após o estabelecimento da conexão, o navegador e o servidor podem trocar mensagens WebSocket livremente, norteados e restringidos pelo que for definido pelos desenvolvedores da aplicação. Para tanto, as partes devem ser capazes de construir e interpretar WebSocket frames, que são as estruturas de dados efetivamente trafegadas no canal de comunicação a nível de aplicação:

Imagem 6: Esquema geral de um WebSocket frame – Fonte: Tempest

Essa estrutura possui um cabeçalho de 16 bits obrigatórios (FIN, RSV, OPCODE, MASK, PAYLOAD LENGTH) e a possibilidade de incluir os bits referentes aos dados do payload (payload data) e uma masking key de 32 bits.

As mensagens propriamente ditas (Ex. “Olá!”, “ping”) são encapsuladas dentro do campo Payload data, podendo ser também fragmentada. Os demais campos são construídos pelo navegador e pelo servidor de forma transparente para o usuário, como por exemplo o bit FIN, que controla a fragmentação de mensagens indicando quando o frame possui o último fragmento de uma mensagem.

Embora a estrutura do WebSocket frame ainda possua muitos pontos a serem discutidos, já cobrimos as noções básicas e necessárias para seguirmos em frente e nos aprofundarmos no tema segurança. Discutiremos a seguir questões de segurança envolvendo o protocolo, com foco nas falhas de segurança comuns em aplicações que o utilizam.

WebSocket e segurança

Embora o protocolo WebSocket delegue alguns pontos de segurança para outros componentes ou para o desenvolvedor, ele ainda carrega um arcabouço de medidas de segurança. Algumas destas são estipuladas ou sugeridas na especificação do protocolo (RFC 6455), outras estabelecidas pelo padrão WebSocket (WebSocket API). 

Discorreremos abaixo, brevemente, sobre pontos de atenção que devem ser levados em conta ao analisarmos cenários de ataque e testes de segurança:

• Autenticação e autorização: Primeiramente, o protocolo WebSocket não possui mecanismos embutidos para fornecer autenticação e autorização dos usuários, cabendo aos desenvolvedores implementarem tais medidas em suas aplicações caso haja necessidade (por exemplo,a utilização de cookies no momento do WebSocket handshake).
• Requisições de outras origens: os navegadores não aplicam a política de mesma origem (Same Origin Policy, SOP) em comunicações WebSocket (incluindo a requisição HTTP de upgrade). Ou seja, por padrão, scripts de origens distintas podem, a priori, se comunicar com servidores WebSocket.

Para ilustrar este fato, podemos comparar abaixo o comportamento do navegador ao executar um Fetch( ) e WebSocket( ) para acessar dados de outra origem. Nos dois casos, tentamos acessar os dados enviados por echo.websocket.org, que suporta comunicação via https:// e wss://:

Imagem 7: Requisição cross-origin utilizando Fetch( ) – Fonte: Tempest

No caso acima, percebe-se que o site atacado não configurou um CORS permissivo e, por isso, a SOP impediu que o script de fetch_sample.html acessasse o recurso.

Já no caso abaixo, utilizando WebSocket( ), vemos que o oposto acontece e, por padrão, o navegador não impede o acesso ao script:

Imagem 8: Requisição cross-origin utilizando WebSocket( ) – Fonte: Tempest

Veremos mais adiante como este comportamento padrão pode ser explorado por um atacante por meio de um ataque conhecido como WebSocket Cross-site Hijacking.

Uso de criptografia

Ao utilizar WebSockets a partir de HTTP/1.1, a upgrade request é quem “determina” se a comunicação ocorrerá através de WebSocket criptografado (wss) ou em texto plano (ws):

• Se a comunicação for iniciada com o esquema wss:// (como na imagem acima), o navegador enviará a requisição de upgrade através de HTTPS. Então a conexão WebSocket será inicializada sobre a camada de criptografia;
• Se utilizar o esquema ws://, a requisição de upgrade será feita em HTTP (texto plano) e a conexão WebSocket será montada diretamente em cima da camada TCP, sem uma camada de criptografia;

Em resumo, no HTTP/1.1, após um handshake bem sucedido, o protocolo WebSocket substitui o HTTP na camada de aplicação, “herdando” a conexão TCP ou TLS/TCP utilizada no handshake. 

No caso de HTTP/2 e HTTP/3, o cenário seria diferente, uma vez que o HTTP/3 funciona sobre o protocolo QUIC, com criptografia embutida, e o HTTP/2 na prática não é aceito sem criptografia pela maioria dos navegadores e serviços de hospedagem. De todo modo, nestes casos o WebSocket handshake não teria a capacidade de alterar aspectos da conexão, vez que atuariam apenas como HTTP streams.

Mascaramento

Masking é uma técnica de ocultação da mensagem WebSocket enviada pelo navegador. Essa ocultação é feita por meio de uma operação XOR utilizando uma chave aleatória (WebSocket-Key). O objetivo deste mecanismo é evitar ataques de envenenamento, sobretudo cache-poisoning.

Como bem explicado em nosso artigo, o cache-poisoning é um ataque no qual uma requisição HTTP maliciosa é formulada para convencer um servidor de cache a armazenar uma resposta maliciosa e fornecê-la aos demais usuários. 

Mascarando-se todas as mensagens do navegador, seu conteúdo se torna não-interpretável por intermediários (por exemplo, cache proxy). O servidor, contudo, precisa simplesmente utilizar a masking key (que é incluída no WebSocket frame), para desmascarar o payload, permitindo ao servidor WebSocket processar seu conteúdo normalmente:

Imagem 9: Payload websocket acessado e desmascarado pelo Wireshark – Fonte: Tempest

Da mesma forma que a ferramenta Wireshark é capaz de desmascarar o payload sem problemas, qualquer outro programa capaz de enviar e receber WebSocket frames também é. Desse modo, é preciso ter em mente que a função do mascaramento é mitigar ataques de poisoning, mas não foi projetado para garantir confidencialidade e integridade.

Medidas anti-open redirect

Embora o mecanismo de redirect seja um componente comum na navegação web, os navegadores possuem o comportamento padrão de não seguir redirects (código 300, 301, 302…) em WebSocket handshakes.

Desse modo, o WebSocket handshake está, por padrão, protegido de vulnerabilidades de open redirect, em que o usuário tentaria acessar um servidor WebSocket legítimo e acaba redirecionado para um servidor malicioso.

Esta medida de proteção não foi estabelecida pela RFC 6455, e sim pela especificação da WebSocket API:

Imagem 10: Trecho da especificação WebSocket API – Fonte: Especificação WebSocket

Ademais, o protocolo WebSocket também não define seus próprios mecanismos de redirect.

Medidas anti-DoS

Algumas medidas para mitigação de ataques de negação de serviço (DoS) foram propostas pela RFC 6455 e são implementadas pelos clientes e servidores compatíveis com a especificação.

Por exemplo, servidores WebSocket devem limitar o número de conexões simultâneas de um mesmo cliente e incluir uma breve pausa antes de encerrar as conexões. Pois isso reduz a frequência de tentativas de reconexão pelo cliente, dificultando que estes esgotem os recursos do servidor.

Os navegadores também possuem medidas similares para mitigar o potencial danoso de navegadores comprometidos, embora estas medidas normalmente possam ser modificadas pelo usuário.

Por fim, as implementações de servidores WebSocket devem contar com limitações de frame-size e message-size, fato que normalmente impedirá cenários de DoS causados simplesmente pelo envio de mensagens longas demais.

Contudo, sempre caberá ao desenvolvedor analisar as medidas anti-DoS já existentes e averiguar se são o suficiente no caso concreto.

• Por exemplo, em nossos testes nos deparamos com um caso em que qualquer mensagem WebSocket mal-formatada acarretava em negação de serviço no servidor. Este problema não foi abarcado pelas medidas anti-DoS do protocolo WebSocket porque reside em um erro de programação (ausência de tratamento de erros).

Até então, este texto buscou resumir os principais pontos sobre o funcionamento e os mecanismos de segurança existentes no protocolo. Então, está formada a base para falarmos agora sobre cenários de ataque contra o WebSocket ou que o utilizam como vetor.

Websockets e pentest

Aprenda testando (com maturidade)

No campo da segurança, sobretudo da segurança ofensiva, boa parte do aprendizado só será adquirido botando a mão na massa. Por isso, testes em ambiente de laboratório muitas vezes são essenciais para o pesquisador compreender as vulnerabilidades em estudo.

Seja desenvolvendo sua própria aplicação, rodando uma aplicação open-source ou mesmo em programas de bug bounty, o estudo prático de vulnerabilidades em aplicações reais permitirão que você extraia conhecimento — e quem sabe agradecimentos ou recompensas — diretamente do mundo real.

No meu caso, subi uma instância local da aplicação open-source de videoconferências MirotalkSFU e realizei os testes nela. É claro, cada problema de segurança encontrado foi devidamente reportado aos  mantenedores do código. Além de aprender, pude colaborar com a segurança da aplicação e ganhar um agradecimento na página.

Mas cuidado: sempre que desejar testar uma aplicação, entenda se você possui a devida autorização para fazê-lo, os limites dessa autorização e, caso encontre vulnerabilidades, verifique qual o canal apropriado para reportar a falha. Evite transtornos.

Nesta seção, explico um pouco sobre vulnerabilidades comuns em aplicações web que utilizam WebSockets. Algumas fui capaz de explorar ao longo dos testes, outras não.

Cross-site WebSocket Hijacking

Primeiramente, falaremos sobre o ataque conhecido como Cross-site WebSocket Hijacking (CSWSH). Este ataque ocorre quando a ação de “inicializar de uma conexão WebSocket” está sujeita a Cross-site Request Forgery, permitindo que um atacante utilize o navegador da vítima para, em nome desta, realizar ações sensíveis em um servidor WebSocket:

Imagem 11: Fluxo geral de ataques de CSRF e CSWSH – Fonte: Tempest

A imagem acima ilustra de maneira simplificada o “fluxo” de um ataque de CSWSH, cuja ideia é a mesma de um CSRF padrão. O atacante envia para a vítima um link malicioso (1) para fazer com que a vítima carregue a página maliciosa em seu navegador (2). A página maliciosa executa um script que, sem a vítima perceber, estabelece uma conexão com o site vulnerável e executa alguma ação sensível e/ou extrai informações sensíveis (3). Em seguida, caso o objetivo seja a extração de informações, a página maliciosa envia para o atacante as informações sensíveis que conseguiu extrair do site vulnerável (4).

A peculiaridade do CSWSH é que o script malicioso (representado pelo passo 3) irá explorar uma conexão WebSocket permissiva do site vulnerável, que não valida a origem da requisição. Para ilustrar:

Imagem 12: Exemplo de script malicioso usado para explorar um CSWSH – Fonte: Tempest

Em um cenário comum de CSRF, o script malicioso poderia enviar a requisição para origem atacada, mas não poderia acessar a resposta. Contudo, a conexão WebSocket maliciosa (incluindo o handshake) é possível porque, como já explicamos anteriormente,  a comunicação WebSocket não está submetida à Política de Mesma Origem.

A vulnerabilidade é mitigada, no entanto, caso a aplicação implemente a verificação da origem como parte da autorização para estabelecer a conexão WebSocket, impedindo assim que scripts de origens potencialmente maliciosas estabeleçam o handshake. No entanto, medidas adicionais de proteção contra CSRF, como o uso de tokens CSRF e a configuração da flag SameSite como Strict, também são essenciais para garantir uma defesa robusta.

Man-in-the-middle

O Man-in-the-middle se refere aos ataques nos quais o atacante é capaz de se posicionar na rede da vítima de modo a possibilitar a visualização, interceptação e modificação do tráfego que parte ou chega ao usuário.

Esse cenário pode ocorrer em aplicações web que não utilizam uma camada de criptografia (por exemplo, TLS) para assegurar a confidencialidade das comunicações. Veremos a seguir que o cenário pode ocorrer também no uso de WebSocket inseguro (ws://) e que a vulnerabilidade pode se apresentar de forma não convencional.

Falamos anteriormente sobre como, no WebSocket iniciado via HTTP/1.1, a comunicação WebSocket “herda” a conexão TLS/TCP que foi utilizada pelas requisição de upgrade. Isso significa que, neste caso, mesmo que determinado website seja carregado exclusivamente através de HTTPS, isso não garante que o WebSocket handshake esteja abarcado pela mesma medida de segurança. Um exemplo desse comportamento que pôde ser identificado na aplicação open-source abaixo, que aceitava apenas requisições via HTTPS, com exceção da requisição de upgrade, que podia ser manipulada em trânsito para utilizar HTTP em texto plano e se conectar com sucesso com o servidor sem criptografia, estabelecendo uma conexão WebSocket insegura:

Imagem 13: Editando a requisição interceptada com o Burp Suite Community – Fonte: Tempest

Este teste acarretou no cenário abaixo, no qual a página, apesar de carregada via HTTPS, está de fato renderizando informações provenientes de uma conexão WebSocket insegura:

Imagem 14: Página HTTPS utilizando WebSocket em texto plano – Fonte: Tempest

Neste cenário, um atacante bem posicionado poderia interceptar a mensagem HTTPS de handshake e alterar o protocolo para HTTP na porta 80 (já que, neste cenário, o servidor não estava bloqueando este tipo de conexão).

Validação de entrada

A validação dos dados enviados pelos usuários através da comunicação é um dos temas mais sensíveis, tendo em vista que o protocolo foi criado para trafegar mensagens independentemente do formato dessas e não possui mecanismos nativos de validação de entrada.

Desse modo, ficará a cargo do desenvolvedor implementar todas as validações de entrada e saída que forem necessárias para assegurar a segurança diante das regras de negócio da aplicação.

A imagem abaixo ilustra exemplos de clássicas vulnerabilidades web que podem existir em uma comunicação WebSocket

Imagem 15: Ilustração de problemas de segurança associados a validação de input em mensagens WebSocket – Fonte: Tempest

Assim, o analista de segurança deve buscar compreender como os dados enviados são utilizados pela aplicação e realizar todos os testes cabíveis, averiguando se os dados estão sendo validados de forma apropriada e se o cenário representa riscos à aplicação e seus usuários.

Um caso extremo foi identificado na aplicação abaixo, que esperava mensagens WebSocket formatadas de uma maneira específica e não possuía tratamento de erros para mensagens que fugissem à regra. Nesse caso, uma simples aspas duplas era capaz de derrubar o servidor, causando a negação do serviço:

Imagem 16: Derrubando um servidor WebSocket vulnerável através de uma simples quebra da sintaxe esperada – Fonte: Tempest

Do outro lado do espectro temos aplicações WebSocket cujo funcionamento não é de fácil entendimento e manipulação pelo Pentester, como por exemplo aquelas que utilizam WebSocket para trafegar dados binários ao invés de texto. Nesses casos, ainda que o entendimento e a subversão da comunicação sejam mais complexos, ainda será possível identificar falhas de segurança caso a aplicação não implemente validações coerentes com suas regras de negócio.

Testando o Comportamento de proxies

Como último tópico, vamos refletir sobre as comunicações WebSocket na presença de proxies reversos. Estes últimos comumente atuam como intermediários alocados “na frente” do servidor web para cumprir função de balanceamento de carga ou para proteger o servidor back-end do acesso direto dos clientes.

Nesses casos, é possível que toda comunicação WebSocket seja intermediada pelo servidor proxy, incluindo a requisição HTTP de upgrade. A imagem abaixo ilustra o fluxo de requisições que estabelecem uma conexão HTTP/1.1 através de um proxy:

Imagem 17: Fluxo de requisições para conexão com servidor através de proxy reverso – Fonte: Tempest

Havendo indícios de um proxy reverso na comunicação, deve-se testar todas as possibilidades de interação disruptiva que possam trazer impactos no contexto da aplicação, pois os servidores back-end e/ou de proxy podem não estar corretamente configurados em relação ao WebSocket handshake.

Um cenário que ilustra bem a situação é aquele em que o back-end ingenuamente valida o IP do usuário através de um cabeçalho como X-Forwarded-For. Este cabeçalho pode ser utilizado pelo back-end para discernir a origem de uma requisição que é entregue por um proxy reverso ou uma cadeia de proxies. 

No entanto, o X-Forwarded-For não deve ser utilizado como mecanismo de autorização ou autenticação, já que pode manipulado pelo atacante e mantido pelo servidor de proxy, levando ao bypass da validação em questão, como controle de acesso baseado em lista permissão ou bloqueio:

Imagem 18: Esquema de um bypass de controle de acesso baseado em lista de bloqueio – Fonte: Tempest

Outro caso, bem mais específico, é o cenário publicado pelo usuário 0ang3el e disposto em forma de lab em seu repositório no GitHub. A vulnerabilidade foi chamada de WebSocket Smuggling e afetava versões antigas dos proxies Varnish e Envoy.

A imagem abaixo ilustra o envio de uma requisição de upgrade mal-formada (cabeçalho Sec-WebSocket-Version) que é aceita pelo proxy mas é rejeitada pelo back-end (código de erro 426). Contudo, o proxy reverso não valida o código da resposta, assumindo erroneamente que uma conexão TCP/TLS deve ser estabelecida para lidar com uma comunicação WebSocket:

Imagem 19: Esquema de um ataque de WebSocket Smuggling – Fonte: https://github.com/0ang3el/websocket-smuggle

A conexão TCP/TLS persistente, contudo, está conectando duas partes que efetivamente não não concluíram o WebSocket handshake, pois o back-end rejeitou a requisição de upgrade. O resultado é que a conexão TCP/TLS acaba servindo como túnel pelo qual o atacante pode acessar via HTTP recursos internos do backend antes não-acessíveis.

Embora o desafio proposto por 0ang3el aponte para falhas específicas em softwares obsoletos, o cenário expõe como a interação entre diferentes componentes que precisam lidar com conexões WebSockets pode resultar em resultados inesperados.

Conclusão

Se você chegou até aqui, deve possuir todas as ferramentas necessárias para incluir o protocolo WebSocket no escopo dos seus testes! Porém, note que a exploração dessas falhas partirá da análise do caso concreto e dependerá fortemente de como a aplicação em questão utiliza o protocolo para trafegar dados entre os componentes front-end e back-end. Por isso, na prática, as vulnerabilidades podem surgir de diversas formas na comunicação, extrapolando o conteúdo deste blogpost. 

Referências

0ang3el/websocket-smuggle: Issues with WebSocket reverse proxying allowing to smuggle HTTP requests.” GitHub, 2019, https://github.com/0ang3el/websocket-smuggle.

Erkkilä, Jussi-Pekka. “WebSocket Security Analysis.” Aalto University School of Science, 2012, https://juerkkil.iki.fi/files/websocket2012.pdf. Accessed 5 February 2024.

IETF, et al. “RFC 6455 The WebSocket Protocol.” RFC Editor, December 2011, https://www.rfc-editor.org/info/rfc6455 . Accessed December 2023.

IETF, et al. “RFC 8441 Bootstrapping WebSockets with HTTP/2” RFC Editor, September 2018, https://www.rfc-editor.org/info/rfc8441. Accessed December 2023.

Ghasemshirazi, Saeid, and Pouya Heydarabadi. “Exploring the Attack Surface of WebSocket.” Cornell University – arXiv, 12 April 2021, https://arxiv.org/abs/2104.05324. Accessed 5 February 2024.

Karlström, Juuso. “The WebSocket protocol and security: best practices and worst weaknesses.” University of Oulu repository, 2016. OULUN YLIOPISTO, https://oulurepo.oulu.fi/handle/10024/6116.

Kuosmanen, Harri. “Security Testing of WebSockets.” THESEUS, Jamk University of Applied Sciences, 18 May 2016, https://www.theseus.fi/bitstream/handle/10024/113390/Harri+Kuosmanen+-+Masters+thesis+-+Security+Testing+of+WebSockets+-+Final.pdf?sequence=1. Accessed January 2024.

PortSwigger. “Testing for WebSockets security vulnerabilities | Web Security Academy.” PortSwigger, https://portswigger.net/web-security/websockets. Accessed December 2023.

WHATWG. “WebSockets Living Standard.” WHATWG, 27 October 2023, https://websockets.spec.whatwg.org//. Accessed January 2024.