Waarom een C-struct een slecht SOCKS-verzoek kan opleveren
Inspecteer expliciete veldbreedtes, bytevolgorde en stream-I/O in plaats van de lay-out van de compiler als het wire-formaat te behandelen.
Een geldig proxyadres maakt een handgeschreven SOCKS-bericht niet geldig. Het versturen van een C- of C++-struct kan opvulling of gehele getallen in hostvolgorde meesturen die het protocol nooit heeft gevraagd.
Voor een SOCKS5 CONNECT-verzoek met domeinnaam serialiseert u deze volgorde expliciet na de methode-onderhandeling en eventuele gekozen authenticatie:
- Versie, opdracht, gereserveerde byte en adrestype
- Domeinlengte en domeinbytes
- De twee-byte bestemmingspoort in netwerk-bytevolgorde
Adreslengtes hangen af van de SOCKS-versie en het adrestype. Numerieke velden met vaste breedte hebben hun voorgeschreven weergave nodig; domeintekenreeksen hebben hun eigen lengtecodering. Een C-string-terminator is geen algemene instructie om een nul aan het wire-bericht toe te voegen.
| Kortsluiting in de implementatie | Probleem om te controleren |
|---|---|
| Een 32-bits waarde toewijzen via een 8-bits pointer | Het geeft niet alle vier bytes weer |
| Een buffer casten naar een pointer naar een groter geheel getal | Uitlijning en bytevolgorde moeten nog steeds worden afgehandeld |
| Aannemen dat één lees- of schrijfactie één bericht is | TCP kan slechts een deel van de protocolvolgorde overdragen |
Vergelijk elk veld met de bedoelde bestemming en verwerk gedeeltelijke I/O. Het ontvangen van twee bytes bewijst niet dat het volledige antwoord is aangekomen. Het onderzoeken van die grenzen kan een misvormd verzoek onderscheiden van een server die een correct beschreven verbinding weigert.