Per què una struct de C pot produir una petició SOCKS dolenta
Inspeccioneu les amplades de camp explícites, l'ordre dels bytes i l'E/S de flux en lloc de tractar la disposició del compilador com el format de xarxa.
Una adreça de proxy vàlida no fa vàlid un missatge SOCKS escrit a mà. Enviar una struct de C o C++ pot enviar farciment o enters en ordre d'amfitrió que el protocol mai no ha demanat.
Per a una petició SOCKS5 CONNECT amb nom de domini, serialitzeu aquesta seqüència explícitament després de la negociació del mètode i de qualsevol autenticació seleccionada:
- Versió, ordre, byte reservat i tipus d'adreça
- Longitud del domini i bytes del domini
- El port de destinació de dos bytes en ordre de bytes de xarxa
Les longituds d'adreça depenen de la versió de SOCKS i del tipus d'adreça. Els camps numèrics d'amplada fixa necessiten la seva representació especificada; les cadenes de domini tenen la seva pròpia codificació de longitud. Un terminador de cadena de C no és una instrucció general per afegir un zero al missatge de xarxa.
| Drecera d'implementació | Problema a comprovar |
|---|---|
| Assignar un valor de 32 bits mitjançant un punter de 8 bits | No emet els quatre bytes |
| Convertir un buffer en un punter a un enter més gran | L'alineació i l'ordre dels bytes encara s'han de gestionar |
| Suposar que una lectura o escriptura és un sol missatge | TCP només pot transferir una part de la seqüència del protocol |
Compareu cada camp amb la destinació prevista i gestioneu l'E/S parcial. Rebre dos bytes no estableix que hagi arribat tota la resposta. Inspeccionar aquests límits pot distingir una petició mal formada d'un servidor que rebutja una connexió descrita correctament.