Por que unha struct de C pode producir unha petición SOCKS defectuosa
Inspeccione os anchos de campo explícitos, a orde de bytes e a E/S de fluxo en lugar de tratar a disposición do compilador como o formato de rede.
Un enderezo de proxy válido non fai válida unha mensaxe SOCKS escrita a man. Enviar unha struct de C ou C++ pode enviar recheo ou enteiros en orde de host que o protocolo nunca solicitou.
Para unha petición SOCKS5 CONNECT con nome de dominio, serialice esta secuencia explicitamente tras a negociación do método e calquera autenticación seleccionada:
- Versión, comando, byte reservado e tipo de enderezo
- Lonxitude do dominio e bytes do dominio
- O porto de destino de dous bytes en orde de bytes de rede
As lonxitudes de enderezo dependen da versión de SOCKS e do tipo de enderezo. Os campos numéricos de ancho fixo necesitan a súa representación especificada; as cadeas de dominio teñen a súa propia codificación de lonxitude. Un terminador de cadea de C non é unha instrución xeral para engadir un cero á mensaxe de rede.
| Atallo de implementación | Problema que comprobar |
|---|---|
| Asignar un valor de 32 bits mediante un punteiro de 8 bits | Non emite os catro bytes |
| Converter un búfer nun punteiro a un enteiro maior | A aliñación e a orde de bytes aínda hai que xestionalas |
| Supoñer que unha lectura ou escritura é unha soa mensaxe | TCP pode transferir só parte da secuencia do protocolo |
Compare cada campo co destino previsto e xestione a E/S parcial. Recibir dous bytes non demostra que chegase toda a resposta. Inspeccionar eses límites pode distinguir unha petición mal formada dun servidor que rexeita unha conexión descrita correctamente.