buffer overrun beskytelse

[Giddion]

Jeg har for tiden prøvd å sette meg inn i buffer overrun problemet. Så det jeg lurer på er hvor mye burde man egentlig beskytte seg mot dette problemet? Burde man fks. bytte ut alle string/minne operasjonen med en sikrere versjon, eller holder det med bytte ut operasjonene som har med nettverket å gjøre?

[teflonpanne]

bruk std::string istedetfor char* og std::vector<T> istedetfor T* osv.

det garanterer ikke at du ikke kan gjøre noe dumt og fortsatt få buffer overrun, men det gjør det mye lettere for deg å programmere "sikkert" samtidig som det går mye fortere siden du generelt har mindre sjangse for å gjøre noe feil og slipper debugging hele tida

[Giddion]

Vel jeg er ikke noen hacker guru, men jeg ville tro at std::string rent sikkerhetsmessig ikke er bedre en char* før man har dataene inn i std::string.

 

Og det skal jo sies at man ikke alltid kan bruker std::string, fks når man leser filer eller får rådata fra fks. nettverk.

[Giddion]

Vel jeg er ikke noen hacker guru, men jeg ville tro at std::string rent sikkerhetsmessig ikke er bedre en char* før man har dataene inn i std::string.

 

Og det skal jo sies at man ikke alltid kan bruker std::string, fks når man leser filer eller får rådata fra fks. nettverk.

[Dead_Rabbit]

Vet ikke helt om jeg fårstår deg rett nå, Giddion, men grunnen til at man bruker std::string er jo for at ting nettopp skal bli "sikrere". std::string kontrollerer jo minnet sitt selv, så brukeren slipper å tenke på det.

[Peter]

Men han har rett i at først må ting puttes inn i en std::string før det er sikkert.

Ta f.eks. sockets. Der er du nødt til å opperere med char arrays før du kan putte arrayet ditt inn i en std::string. Dersom du leser mer enn du har allokert, er du ille ute.

[Dead_Rabbit]

Ja, det er sant. Pleier alltid å sende en int som beskriver hvor mye jeg skal sende først jeg. Så lager jeg char*en basert på det. Kansje litt tregere enn det ellers ville ha blitt men.

[dayslepr]

fordelen ved å bruke std-biblioteket her er at du bruker pointer-manipulering og array-stuff på et lite isolert område av koden din --- altså du wrapper socket send/recv o.l. .... presto; problem løst

[Peter]

jaja, seff, men det er der problemene kan oppstå, mener jeg.

Er ikke så lett å få bufferfeil senere kun ved bruk av standardklassene

[Giddion]

Beklager at jeg var litt uklar, men jeg tenkte på det samme som Nazgul

 

  Men han har rett i at først må ting puttes inn i en std::string før det er sikkert.

Ta f.eks. sockets. Der er du nødt til å opperere med char arrays før du kan putte arrayet ditt inn i en std::string. Dersom du leser mer enn du har allokert, er du ille ute.

Men dette gjelder jo andre ting også som fks. fopen

[Peter]

Vi bruker da ikke fopen i C++!

std::fstream er din venn.

 

Eneste stedet jeg kan tenke meg at du må bruke char arrays in fstream er i read(), som du strengt tatt bare bruker når du driver med binæropperasjoner(Gjelder ihvertfall meg), og da lager du bare en liten wrapper, som dayslepr sa.

Endret 10. november 2005 av Nazgul

[Giddion]

men jeg koder jo ikke alltid i C++, av å til syntes jeg det passer bedre med C

[Peter]

Det er greit nok, men i forhold til hva alle andre har postet her (C++), så burde man bruke std::fstream for å sikre seg best mulig mot nettopp buffer overrun.

C har ikke disse fine wrapperene