Зошто C структура може да создаде лош SOCKS барање
Проверете ги експлицитните ширини на полињата, редоследот на бајти и стрим I/O наместо распоредот од компајлерот да го сметате за мрежен формат.
Валидна адреса на прокси не прави рачно напишаната SOCKS порака валидна. Испраќање C или C++ структура може да испрати пополнување или цели броеви по редослед на домаќин што протоколот никогаш не ги побарал.
За SOCKS5 CONNECT барање со име на домен, серијализирајте ја оваа низа експлицитно по преговорот за метод и избраната автентикација:
- Верзија, команда, резервиран бајт и тип на адреса
- Должина на доменот и бајти на доменот
- Двобајтниот порт на дестинацијата во мрежен редослед на бајти
Должините на адресите зависат од верзијата на SOCKS и типот на адреса. Нумеричките полиња со фиксна ширина бараат нивно определено претставување; доменските низи имаат свое кодирање на должината. Терминаторот на C низа не е општа инструкција да се додаде нула на мрежната порака.
| Кратенка во имплементацијата | Проблем што треба да се провери |
|---|---|
| Доделување 32-битна вредност преку 8-битен показател | Не ги испишува сите четири бајти |
| Претворање на бафер во показател на поголем цел број | Порамнувањето и редоследот на бајти сè уште треба да се обработат |
| Претпоставка дека едно читање или пишување е една порака | TCP може да пренесе само дел од низата на протоколот |
Споредете го секое поле со предвидената дестинација и обработете делумен I/O. Примањето два бајта не докажува дека пристигнал целиот одговор. Прегледот на тие граници може да разликува неисправно барање од сервер што одбива правилно опишана врска.