Perché una struct C può produrre una richiesta SOCKS difettosa
Ispezionate le larghezze di campo esplicite, l'ordine dei byte e l'I/O di flusso invece di trattare la disposizione del compilatore come il formato di rete.
Un indirizzo proxy valido non rende valido un messaggio SOCKS scritto a mano. Inviare una struct C o C++ può inviare riempimento o interi in ordine host che il protocollo non ha mai richiesto.
Per una richiesta SOCKS5 CONNECT con nome di dominio, serializzate questa sequenza esplicitamente dopo la negoziazione del metodo e qualsiasi autenticazione selezionata:
- Versione, comando, byte riservato e tipo di indirizzo
- Lunghezza del dominio e byte del dominio
- La porta di destinazione a due byte nell'ordine dei byte di rete
Le lunghezze degli indirizzi dipendono dalla versione di SOCKS e dal tipo di indirizzo. I campi numerici a larghezza fissa richiedono la rappresentazione specificata; le stringhe di dominio hanno la propria codifica di lunghezza. Un terminatore di stringa C non è un'istruzione generale per aggiungere uno zero al messaggio di rete.
| Scorciatoia implementativa | Problema da verificare |
|---|---|
| Assegnare un valore a 32 bit tramite un puntatore a 8 bit | Non emette tutti e quattro i byte |
| Convertire un buffer in un puntatore a un intero più grande | Allineamento e ordine dei byte vanno ancora gestiti |
| Presumere che una lettura o scrittura sia un solo messaggio | TCP può trasferire solo una parte della sequenza del protocollo |
Confrontate ogni campo con la destinazione prevista e gestite l'I/O parziale. Ricevere due byte non dimostra che sia arrivata l'intera risposta. Esaminare quei confini può distinguere una richiesta malformata da un server che rifiuta una connessione descritta correttamente.