Warum eine C-Struktur eine fehlerhafte SOCKS-Anfrage erzeugen kann
Prüfen Sie explizite Feldbreiten, Byte-Reihenfolge und Stream-I/O, statt das Compiler-Layout als Wire-Format zu behandeln.
Eine gültige Proxyadresse macht eine handgeschriebene SOCKS-Nachricht nicht gültig. Das Senden einer C- oder C++-Struktur kann Padding oder Ganzzahlen in Host-Reihenfolge übertragen, die das Protokoll nie verlangt hat.
Für eine SOCKS5-CONNECT-Anfrage mit Domainnamen serialisieren Sie diese Reihenfolge explizit nach der Methodenaushandlung und einer eventuell gewählten Authentifizierung:
- Version, Befehl, reserviertes Byte und Adresstyp
- Domainlänge und Domain-Bytes
- Der zwei Byte große Zielport in Netzwerk-Byte-Reihenfolge
Adresslängen hängen von der SOCKS-Version und dem Adresstyp ab. Numerische Felder fester Breite benötigen ihre festgelegte Darstellung; Domain-Strings haben ihre eigene Längenkodierung. Ein C-String-Terminator ist keine allgemeine Anweisung, der Wire-Nachricht eine Null anzuhängen.
| Abkürzung in der Umsetzung | Zu prüfendes Problem |
|---|---|
| Einem 32-Bit-Wert über einen 8-Bit-Zeiger zuweisen | Es werden nicht alle vier Bytes ausgegeben |
| Einen Puffer auf einen Zeiger auf eine größere Ganzzahl casten | Ausrichtung und Byte-Reihenfolge müssen weiterhin behandelt werden |
| Annehmen, ein Lese- oder Schreibvorgang sei eine Nachricht | TCP kann nur einen Teil der Protokollfolge übertragen |
Vergleichen Sie jedes Feld mit dem beabsichtigten Ziel, und behandeln Sie partielles I/O. Das Empfangen von zwei Bytes beweist nicht, dass die gesamte Antwort angekommen ist. Die Prüfung dieser Grenzen kann eine fehlerhafte Anfrage von einem Server unterscheiden, der eine korrekt beschriebene Verbindung ablehnt.