Pse një struct C mund të prodhojë një kërkesë të keqe SOCKS
Inspektoni gjerësitë e qarta të fushave, rendin e bajteve dhe I/O-n e rrjedhës në vend që të trajtoni planin e përpiluesit si formatin e rrjetit.
Një adresë e vlefshme proxy nuk e bën të vlefshme një mesazh SOCKS të shkruar me dorë. Dërgimi i një struct C ose C++ mund të dërgojë mbushje ose numra të plotë në rendin e hostit që protokolli nuk i kërkoi kurrë.
Për një kërkesë SOCKS5 CONNECT me emër domain, serializoni këtë sekuencë në mënyrë të qartë pas negociimit të metodës dhe çdo vërtetimi të zgjedhur:
- Versioni, komanda, bajti i rezervuar dhe lloji i adresës
- Gjatësia e domain-it dhe bajtet e domain-it
- Porti i destinacionit prej dy bajtesh në rendin e bajteve të rrjetit
Gjatësitë e adresave varen nga versioni i SOCKS dhe lloji i adresës. Fushat numerike me gjerësi fikse kërkojnë paraqitjen e tyre të përcaktuar; vargjet e domain-it kanë kodimin e vet të gjatësisë. Terminatori i vargut C nuk është udhëzim i përgjithshëm për të shtuar një zero në mesazhin e rrjetit.
| Shkurtore zbatimi | Problem për t'u verifikuar |
|---|---|
| Caktimi i një vlere 32-bitëshe përmes një treguesi 8-bitësh | Nuk i nxjerr të katër bajtet |
| Konvertimi i një buferi në tregues të një numri më të madh të plotë | Rreshtimi dhe rendi i bajteve ende duhet të trajtohen |
| Supozimi se një lexim ose shkrim është një mesazh | TCP mund të transferojë vetëm një pjesë të sekuencës së protokollit |
Krahasoni çdo fushë me destinacionin e synuar dhe trajtoni I/O-n e pjesshme. Marrja e dy bajteve nuk vërteton se ka mbërritur e gjithë përgjigjja. Inspektimi i këtyre kufijve mund të dallojë një kërkesë të keqformuar nga një server që refuzon një lidhje të përshkruar saktë.