Pourquoi une structure C peut produire une mauvaise requête SOCKS
Inspectez les largeurs de champs explicites, l'ordre des octets et les E/S en flux au lieu de traiter la disposition du compilateur comme le format sur le fil.
Une adresse de proxy valide ne rend pas valide un message SOCKS écrit à la main. Envoyer une structure C ou C++ peut transmettre du remplissage ou des entiers dans l'ordre de l'hôte que le protocole n'a jamais demandés.
Pour une requête SOCKS5 CONNECT par nom de domaine, sérialisez cette séquence explicitement après la négociation de méthode et toute authentification sélectionnée :
- Version, commande, octet réservé et type d'adresse
- Longueur du domaine et octets du domaine
- Le port de destination sur deux octets dans l'ordre des octets réseau
Les longueurs d'adresse dépendent de la version de SOCKS et du type d'adresse. Les champs numériques de largeur fixe nécessitent leur représentation spécifiée ; les chaînes de domaine ont leur propre encodage de longueur. Un terminateur de chaîne C n'est pas une instruction générale pour ajouter un zéro au message sur le fil.
| Raccourci d'implémentation | Problème à vérifier |
|---|---|
| Affecter une valeur 32 bits via un pointeur 8 bits | Il n'émet pas les quatre octets |
| Convertir un tampon en pointeur vers un entier plus grand | L'alignement et l'ordre des octets restent à gérer |
| Supposer qu'une lecture ou écriture est un seul message | TCP ne peut transférer qu'une partie de la séquence du protocole |
Comparez chaque champ avec la destination visée et gérez les E/S partielles. Recevoir deux octets ne prouve pas que la réponse entière est arrivée. Examiner ces frontières permet de distinguer une requête malformée d'un serveur qui refuse une connexion correctement décrite.