ทำไม struct ของ C จึงสร้างคำขอ SOCKS ที่ผิดพลาดได้
ตรวจสอบความกว้างของฟิลด์อย่างชัดเจน ลำดับไบต์ และ I/O แบบสตรีม แทนที่จะถือว่าเลย์เอาต์ของคอมไพเลอร์คือรูปแบบบนสาย
ที่อยู่พร็อกซีที่ถูกต้องไม่ได้ทำให้ข้อความ SOCKS ที่เขียนด้วยมือถูกต้อง การส่ง struct ของ C หรือ C++ อาจส่งแพดดิงหรือจำนวนเต็มตามลำดับโฮสต์ที่โปรโตคอลไม่เคยร้องขอ
สำหรับคำขอ SOCKS5 CONNECT ที่มีชื่อโดเมน ให้ทำซีเรียลไลซ์ลำดับนี้อย่างชัดเจนหลังการเจรจาวิธีและแอตเทนติเคชันที่เลือกไว้:
- เวอร์ชัน คำสั่ง ไบต์ที่สงวนไว้ และประเภทที่อยู่
- ความยาวโดเมนและไบต์ของโดเมน
- พอร์ตปลายทางสองไบต์ตามลำดับไบต์ของเครือข่าย
ความยาวที่อยู่ขึ้นอยู่กับเวอร์ชันของ SOCKS และประเภทที่อยู่ ฟิลด์ตัวเลขที่มีความกว้างคงที่ต้องมีรูปแบบที่กำหนดไว้ สตริงโดเมนมีวิธีเข้ารหัสความยาวของตัวเอง ตัวสิ้นสุดสตริง C ไม่ใช่คำสั่งทั่วไปให้เติมศูนย์ลงในข้อความบนสาย
| ทางลัดในการใช้งาน | ปัญหาที่ต้องตรวจ |
|---|---|
| กำหนดค่า 32 บิตผ่านพอยน์เตอร์ 8 บิต | ไม่ส่งออกทั้งสี่ไบต์ |
| แคสต์บัฟเฟอร์เป็นพอยน์เตอร์จำนวนเต็มที่ใหญ่กว่า | ยังต้องจัดการการจัดแนวและลำดับไบต์ |
| สมมติว่าการอ่านหรือเขียนหนึ่งครั้งคือหนึ่งข้อความ | TCP สามารถถ่ายโอนได้เพียงบางส่วนของลำดับโปรโตคอล |
เปรียบเทียบแต่ละฟิลด์กับปลายทางที่ต้องการและจัดการ I/O บางส่วน การได้รับสองไบต์ไม่ได้พิสูจน์ว่าคำตอบทั้งหมดมาถึงแล้ว การตรวจสอบขอบเขตเหล่านั้นสามารถแยกคำขอที่ผิดรูปออกจากเซิร์ฟเวอร์ที่ปฏิเสธการเชื่อมต่อที่อธิบายไว้อย่างถูกต้อง