Por qué una struct de C puede producir una petición SOCKS defectuosa
Inspeccione los anchos de campo explícitos, el orden de bytes y la E/S de flujo en lugar de tratar la disposición del compilador como el formato de red.
Una dirección de proxy válida no hace válido un mensaje SOCKS escrito a mano. Enviar una struct de C o C++ puede enviar relleno o enteros en orden de host que el protocolo nunca solicitó.
Para una petición SOCKS5 CONNECT con nombre de dominio, serialice esta secuencia explícitamente tras la negociación del método y cualquier autenticación seleccionada:
- Versión, comando, byte reservado y tipo de dirección
- Longitud del dominio y bytes del dominio
- El puerto de destino de dos bytes en orden de bytes de red
Las longitudes de dirección dependen de la versión de SOCKS y del tipo de dirección. Los campos numéricos de ancho fijo necesitan su representación especificada; las cadenas de dominio tienen su propia codificación de longitud. Un terminador de cadena de C no es una instrucción general para añadir un cero al mensaje de red.
| Atajo de implementación | Problema que hay que comprobar |
|---|---|
| Asignar un valor de 32 bits mediante un puntero de 8 bits | No emite los cuatro bytes |
| Convertir un búfer en un puntero a un entero mayor | La alineación y el orden de bytes aún deben gestionarse |
| Suponer que una lectura o escritura es un solo mensaje | TCP puede transferir solo parte de la secuencia del protocolo |
Compare cada campo con el destino previsto y gestione la E/S parcial. Recibir dos bytes no demuestra que haya llegado toda la respuesta. Inspeccionar esos límites puede distinguir una petición mal formada de un servidor que rechaza una conexión descrita correctamente.