Új hozzászólás Aktív témák

• #5026 fordfairlane veterán Sk8erPeter #5025

  Új Válasz 2010-07-23 01:17:21 #5026

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  fordfairlane

  veterán

  válasz Sk8erPeter #5025 üzenetére

  Akkor magyarul ilyen esetben csak az a megoldás, hogy ha automatikusan escape-elődik pl. az összes $_POST érték, és ezzel tisztában vagyunk, akkor először alkalmazzuk a stripslashes() fv.-t, majd a mysql_real_escape_string() fv.-t az adatbázisba való feltöltéshez (amit amúgy is kellene, csak a stripslashes() nélkül már duplán lenne escape-elve)?

  A megoldás az lesz, hogy PHP 6-ban már eleve nem is lesz ilyen opció, végleg eltűnik, akárcsak a register_globals.

  Csak mert nálam is van egy hasonló probléma, de a mysql_real_escape_string() fv.-t nem szeretném elhagyni, mert ki tudja, később nem lesz-e PHP-verzió-váltás vagy egyéb módosítás (pl. az általad említett opció kikapcsolása).

  Annak idején mikor a PHP-ba belekerült ez az automatizmus, az egyszerű használhatóság volt a jelszóé s a biztosnág, mivel a kiescapeletlen stringek együtt a register_globalssal azt eredményezte, hogy tömegével készültek a könnyen feltörhető PHP oldalak. Azonban az alapelv eleve hibás. Azt feltételezi, hogy ha kapsz egy stringértéket $_GET, $_POST vagy $_COOKIES-en keresztül, azt te szinte minden esetben adatbázisműveletre használod fel. Régebben talán igaz lehetett ez, amikor a PHP kezdetleges volt, egyetlen előnye az egyszerű használhatóság volt, de ma már a PHP rengeteg dolgot tud, ami nem adatbáziskezeléssel kapcsolatos.

  Egyébként sajnos így van, ha van rá esély, hogy a magic_quotes_gpc be lesz kapcsolva a scripted felhasználása helyén, akkor a stripslashes-t kell feltételes módban és tömbre rekurzívan meghívni, mielőtt bármi műveletet hajtasz végre a stringparaméterekkel.

  [ Szerkesztve ]

  x gon' give it to ya

Új hozzászólás Aktív témák