چرا یک ساختار C می‌تواند درخواست SOCKS بدی تولید کند
به‌جای در نظر گرفتن چیدمان کامپایلر به‌عنوان قالب شبکه، عرض صریح فیلدها، ترتیب بایت و ورودی/خروجی جریانی را بررسی کنید.
نشانی معتبر پروکسی، پیام SOCKS دست‌نویس را معتبر نمی‌کند. ارسال یک ساختار C یا C++ می‌تواند پرکننده یا اعداد صحیح با ترتیب میزبان بفرستد که پروتکل هرگز آن را نخواسته است.
برای درخواست SOCKS5 از نوع CONNECT با نام دامنه، این توالی را پس از مذاکره روش و هر احراز هویت انتخاب‌شده به‌صورت صریح سریال کنید:
- نسخه، فرمان، بایت رزرو‌شده و نوع نشانی
- طول دامنه و بایت‌های دامنه
- درگاه مقصد دو‌بایتی به ترتیب بایت شبکه
طول نشانی‌ها به نسخه SOCKS و نوع نشانی بستگی دارد. فیلدهای عددی با عرض ثابت به نمایش مشخص‌شده خود نیاز دارند؛ رشته‌های دامنه کدگذاری طول خود را دارند. پایان‌بخش رشته C دستور عمومی برای افزودن صفر به پیام شبکه نیست.
| میان‌بر پیاده‌سازی | مشکلی که باید بررسی شود |
|---|---|
| اختصاص یک مقدار 32 بیتی از طریق اشاره‌گر 8 بیتی | هر چهار بایت را منتشر نمی‌کند |
| تبدیل یک بافر به اشاره‌گر عدد صحیح بزرگ‌تر | هم‌ترازی و ترتیب بایت هنوز باید مدیریت شود |
| فرض اینکه یک خواندن یا نوشتن یک پیام است | TCP می‌تواند تنها بخشی از توالی پروتکل را منتقل کند |
هر فیلد را با مقصد مورد نظر مقایسه کنید و ورودی/خروجی جزئی را مدیریت کنید. دریافت دو بایت ثابت نمی‌کند که کل پاسخ رسیده است. بررسی این مرزها می‌تواند درخواست بدشکل را از سروری که یک اتصال درست توصیف‌شده را رد می‌کند تشخیص دهد.