ugrás a tartalomhoz

_GET,_POST,register_globals

csla · 2005. Már. 28. (H), 16.21
Sziasztok!

Van egy webes alkalmazásom, amit annak idején még a _POST és a _GET használata nélkül készítettem el. Most úgy alakult, hogy hirtelen másik szerverre kell költözni, ahol 5-ös PHP van az eddigi 4-es sorozatú helyett, és úgy néz ki, ez gondot fog okozni a register_globals miatt. Mivel elég hirtelen kell költözni, és az összes script változóit átírogatni nem fél perces munka, arra gondoltam, hogy átmenetileg azt csinálom, hogy minden script elejére include-olom a következő kis kódrészletet:

foreach($_GET as $key => $val)
  {
   eval('$'.$key.' = "'.$val.'";');
  };
foreach($_POST as $key => $val)
  {
   eval('$'.$key.' = "'.$val.'";');
  };
Szerintetek ez átmenetileg, míg szépen átírom a kódokat jó megoldás, vagy van valami hátulütője, amire esetleg nem gondoltam?
‹ unexpected t_object_operator PHP kód titkosítása ›
 ■
1

.htaccess, változó változók

Őry Máté · 2005. Már. 28. (H), 16.29
1) ha lehet, .htaccessból be lehet kapcsolni a register_globalst
2) minek eval? $$key=$val;

Maat
2

1) ha lehet, akkor igen (na,

csla · 2005. Már. 28. (H), 16.46
1) ha lehet, akkor igen (na, ez jó megállapítás :))
2) igaz, köszönöm (egyébként az eval-nak van valami hátránya?)
3

> egyébként az eval-nak

Őry Máté · 2005. Már. 28. (H), 17.43
> egyébként az eval-nak van valami hátránya?

ehhez mit szólsz?
http://valami.hu/oldalad.php?valami=1;phpinfo()

Maat
4

Szerintem semmi extra

csla · 2005. Már. 28. (H), 18.42
Szerintem semmi extra nem történik, mert nem az van, hogy eval($valami), hanem eval('$valami="1;phpinfo()"'), így simán stringként kezelődik.
5

eval - evil

Hodicska Gergely · 2005. Már. 28. (H), 19.12
Szia!

Szerintem semmi extra nem történik, mert nem az van, hogy eval($valami), hanem eval('$valami="1;phpinfo()"'), így simán stringként kezelődik.

Lehet az URL-be "-t is írni. ;)

Ahol csak lehet érdemes kerülni az eval-t. Általában biztonsági szemszögéből nézve is körültekintően kell bánni vele, ráadásul elég lassú jószág, ezért is érdemes kerülni.

Az eredeti hozzászólásra pedig: extract($_GET); extract($_POST);


Felhő
6

Próbálgattam rávenni a

csla · 2005. Már. 28. (H), 19.24
Próbálgattam rávenni a scriptet, hogy valahogy végrehajtsa mégis az URL-ben "beküldött" phpinfo()-t, de sehogy sem sikerült, mindig sztringként kezelte az = után lévő értéket.
De a lassúság meggyőző, az extract meg még inkább :)
8

nem eléggé ;-)

Hodicska Gergely · 2005. Már. 28. (H), 21.24
<?php
	eval('$foo = "'.$_GET['foo'].'";');
	echo $foo;
?>
http://felho/eval.php?foo=bar%22;phpinfo();$foo=%22bar


Felhő
9

Kipróbáltam, amit írtál,

csla · 2005. Már. 28. (H), 22.26
Kipróbáltam, amit írtál, nálam ezt adta eredményül:

bar";phpinfo();bar\";phpinfo();$foo=\"bar="bar
10

magic_quotes

Hodicska Gergely · 2005. Már. 28. (H), 22.42
Mert nálad a fenti be van kapcsolva, de ez nem az ajánlott mód, és a legtöbb helyen ki is van kapcsolva.


Felhő
11

Aha, így már értem. Bár

csla · 2005. Már. 28. (H), 22.52
Aha, így már értem. Bár azt nem értem, hogy ha így megakadályozza az ilyesmit, akkor miért nem ajánlott?
12

hamis biztonságérzet

Hodicska Gergely · 2005. Már. 29. (K), 00.01
Jelen esetben kb. csak véletlen, hogy "megvéd", alapvetően az SQL injection támadások elleni védelem lenne a célja, de a megoldás több sebből is vérzik, ugyanis az adatok nem feltétlenül kerülnek adatbázisba, ilyenkor a felesleges escapelés hatását eéiminálnunk kell, másrészt a különböző adatbázisok esetén a vezerlő karakterek escapelése más módon történhet, mint ahogy a magic_quote teszi.


Felhő
7

import

attlad · 2005. Már. 28. (H), 19.25
@import_request_variables('GPC');

Attila