Zergatik C struct batek SOCKS eskaera txarra sor dezakeen
Aztertu eremu-zabalera esplizituak, byte-ordena eta fluxu-I/Oa, konpiladorearen diseinua sareko formatutzat hartu beharrean.
Proxy helbide baliozkoa izateak ez du eskuz idatzitako SOCKS mezua baliodun egiten. C edo C++ struct bat bidaltzeak protokoloak inoiz eskatu ez zuen betegarria edo ostalari-ordenean dauden osokoak bidal ditzake.
SOCKS5 domeinu-izeneko CONNECT eskaera baterako, serializatu segida hau modu esplizituan metodoaren negoziazioaren eta hautatutako autentifikazioaren ondoren:
- Bertsioa, komandoa, erreserbatutako bytea eta helbide mota
- Domeinuaren luzera eta domeinuaren byteak
- Bi byteko helburuko ataka sareko byte-ordenan
Helbideen luzerak SOCKS bertsioaren eta helbide motaren araberakoak dira. Zabalera finkoko eremu numerikoek beren irudikapen zehaztua behar dute; domeinu-kateek beren luzera-kodifikazioa dute. C katearen terminatzailea ez da sare-mezuari zero bat eransteko argibide orokorra.
| Inplementazio-laburrera | Egiaztatu beharreko arazoa |
|---|---|
| 32 biteko balioa 8 biteko erakusle baten bidez esleitzea | Ez ditu lau byteak igortzen |
| Buffer bat osoko handiago baten erakuslera bihurtzea | Lerrokatzea eta byte-ordena oraindik kudeatu behar dira |
| Irakurketa edo idazketa bat mezu bat dela suposatzea | TCPk protokolo-segidaren zati bat baino ezin du transferitu |
Konparatu eremu bakoitza xede den helmugarekin eta kudeatu I/O partziala. Bi byte jasotzeak ez du frogatzen erantzun osoa iritsi denik. Muga horiek aztertzeak eskaera gaizki eratua eta behar bezala deskribatutako konexio bat ukatzen duen zerbitzaria bereiz ditzake.