Por que uma struct C pode produzir um pedido SOCKS defeituoso
Inspecione larguras de campo explícitas, ordem dos bytes e E/S em fluxo em vez de tratar o layout do compilador como o formato de rede.
Um endereço de proxy válido não torna válida uma mensagem SOCKS escrita à mão. Enviar uma struct C ou C++ pode enviar preenchimento ou inteiros na ordem do host que o protocolo nunca pediu.
Para um pedido SOCKS5 CONNECT com nome de domínio, serializa esta sequência explicitamente após a negociação do método e qualquer autenticação selecionada:
- Versão, comando, byte reservado e tipo de endereço
- Comprimento do domínio e bytes do domínio
- A porta de destino de dois bytes na ordem de bytes de rede
Os comprimentos de endereço dependem da versão do SOCKS e do tipo de endereço. Os campos numéricos de largura fixa precisam da representação especificada; as cadeias de domínio têm a sua própria codificação de comprimento. Um terminador de cadeia C não é uma instrução geral para acrescentar um zero à mensagem de rede.
| Atalho de implementação | Problema a verificar |
|---|---|
| Atribuir um valor de 32 bits através de um ponteiro de 8 bits | Não emite os quatro bytes |
| Converter um buffer num ponteiro para um inteiro maior | O alinhamento e a ordem dos bytes ainda têm de ser tratados |
| Assumir que uma leitura ou escrita é uma só mensagem | O TCP só pode transferir parte da sequência do protocolo |
Compare cada campo com o destino pretendido e trate a E/S parcial. Receber dois bytes não prova que chegou a resposta completa. Inspecionar esses limites pode distinguir um pedido malformado de um servidor que recusa uma ligação corretamente descrita.