ugrás a tartalomhoz

Register_Globals Off beállítás "kicselezése"

Anonymous · 2006. Május. 29. (H), 10.58
Sziasztok!!!

Még nagyon kezdő PHP-s vagyok! Írtam egy kezdetleges PHP oldalt, leginkább csak változók és include parancsok vannak a kódomban. Feltöltöttem a tárhelyünkre az oldalt és se a változókat se az include-okat nem kezeli a szerver, ugye a Register_Globals parancs van OFF-on! De a rendszergazda nem kapcsolja be és azt mondta, hogy valahogy ki lehet "cselezni", hogy mégis működjön az oldal. Nézzétek csak meg www.latrinaklan.hu/test/ és ennyi ha oldat kattintatok a menüben nem jön be semmi csak a Hírek modul mert az az alapméretezett modul ami bejön. Szóval ha valaki tudna segíteni nekem, az legyen szíves úgy írjon vissza mint egy igazi kezdőnek mert az is vagyok :D

Üdv White_Pony
‹ Parse error: syntax error, unexpected T_VARIABLE Regisztráció több oldalra egyszerre ›
 ■
1

ne "cselezz", hanem írd át a kódot

zsepi · 2006. Május. 29. (H), 11.13
Ahol eddig reg.glob. változónevet használtál, pl. 
$menu_id
, ott ezentúl 
$_REQUEST['menu_id']
használj
2

Ne hackelj, gondolkozz

Anonymous · 2006. Május. 29. (H), 11.59
Nea register globals-t akard kicselezni, hanem irj olyan programot ami igy is müködik. Mellék állásban biztonságosabb is lessz.

Ajánlamán a $_GET és a $_POST változókat.

Az include-jaindál meg ne azt ird hogy:
include ($module)

hanem valahogy igy:

<?php
if isset($_GET['module'])
{
$_GET['module'] = str_replace('..', '', $_GET['module']);
if (is_file('./modulok/' . $module . '.php')
{
include ('./modulok/' . $module . '.php');
}
else
{
include ('./modulok/main.php');
}
}
else
{
include ('./modulok/main.php');
}
3

$_REQUEST

Anonymous · 2006. Május. 29. (H), 12.35
$_GET + $_POST = $_REQUEST, így nem kell tudni, milyen módszerrel érkezett az adat.
4

Pontatlan

Török Gábor · 2006. Május. 29. (H), 13.50
Ez egyfelől pontatlan ($_REQUEST alá tartozik pl. a $_COOKIE és $_FILES is), másfelől általában a GET-tel érkezők adatokat nem célszerű szerintem hagyni, hogy POST-ként is jöhessenek és fordítva.
25

már nem

Hodicska Gergely · 2006. Jún. 1. (Cs), 01.29
Az újabb PHP verziókban már nincs benne a $_FILES a $_REQUEST-ben.

a GET-tel érkezők adatokat nem célszerű szerintem hagyni, hogy POST-ként is jöhessenek és fordítva

Hirtelen egy elvetemültebb ötletem lenne, hogy ennek mikor lehet jelentősége, de előtte kíváncsi lennék, hogy Te mire gondolsz itt.


Felhő
5

nem kell, de nem árt

Marcell · 2006. Május. 29. (H), 13.56
Nem kell, de nem árt tudni! :) ahogy az előttem lévő üzenetben is olvasod. Sok bug kikerülhető így a későbbiekben.
6

Konkrétan

Anonymous · 2006. Május. 29. (H), 15.04
milyen hibákat okozhat?
8

gondolj bele

Anonymous · 2006. Május. 29. (H), 15.30
például a $_GET és $_POST is tartalmaz azonos indexű elemet.

<?php
echo sprintf('get vagyok: %s <br>',$_GET['modul']);
echo sprintf('post vagyok: %s <br>',$_POST['modul']);
echo sprintf('én mi vagyok? %s <br>',$_REQUEST['modul']);
?>
gex
10

hogyan?

zsepi · 2006. Május. 29. (H), 15.50
például a $_GET és $_POST is tartalmaz azonos indexű elemet.

erre mondanál példát, hogyan is? egy php oldal lekérése csak egyféle kéréssel lehet - vagy POST, vagy GET. Persze a cookie-kkal már lehet ilyen probléma.
11

Vajon ebből mi lesz?

Anonymous · 2006. Május. 29. (H), 16.01
<form action="index.php?action=login" method="post">
<input type="hiden" name="action" value="register">
<input type="submit" value="küld">
</form>
12

tessék

Anonymous · 2006. Május. 29. (H), 16.03
<form action="valami.php?modul=get_vagyok" method="post">
<input type="text" name="modul" value="post_vagyok">
<input type="submit" value="küld">
</form>


gex
15

jó pap

zsepi · 2006. Május. 29. (H), 16.17
is holtig.
13

Szerintem tervezési hiba

Anonymous · 2006. Május. 29. (H), 16.09
ha ugyanolyan nevű elem van a postban és getben.

A harmadik esetben postra tippelek, szerintem az felülírja a getet.

jb
20

Szerintem meg...

Anonymous · 2006. Május. 29. (H), 18.34
Szerintem meg a REQUEST használata a tervezési hiba.
Amúgy meg be lehet állítani ezt a "sorrendet".
26

extract - register globals okosan

krey · 2006. Jún. 1. (Cs), 09.46

<?
extract($_GET,EXTR_PREFIX_ALL,"g");    //extracting $_GET
extract($_POST,EXTR_PREFIX_ALL,"p");   //extracting $_POST
?>
A $_POST["modul"] változót $p_modul alatt érheted el, a $_GET["modul"]t pedig $g_modulként

krey
27

ennek sok értelme nincs

Anonymous · 2006. Jún. 1. (Cs), 10.08
a kérdés sz volt, hogy a $_REQUEST['modul'] mi lesz, ha a $_GET és $_POST tömbnek is van modul indexű eleme. ezt mint lehetséges hibaforrást említettem a $_REQUEST tömb használatakor. az extract függvény ezen nem segít, legalábbis én nem látom nagy jelentőségét annak, hogy $_GET['modul'] és $_POST['modul'] helyett $g_modul-t és $p_modul-t írok.

ráadásul ha más munkájába kell belenéznem, akkor még zavaró is lehet egy ilyen forma.

gex
29

nem gond

Hodicska Gergely · 2006. Jún. 1. (Cs), 12.57
Ebből nem lesz gond, hiszen register_globals on esetén is fennáll ez a probléma. A felülírás sorrendjét ott a gpc_order határozza meg, illetve most már helyette a variables_order az ajánlott.

Amúgy meg nem elég csak a $_GET, $_POST, $_COOKIE, $_FILES ra extract-ot nyomni, mert pl. $PHP_SELF változót még nem lesz ettől, szóval a $_SERVER-t is ki kéne nyomni, ha már ilyen irányba megy el az ember.


Felhő
30

register_globals on

Anonymous · 2006. Jún. 1. (Cs), 13.28
register_globals on esetén is fennáll ez a probléma

persze, pont ezért (is) hasznos a $_GET és $_POST tömb. ebből a szempontból nem jobb a $_REQUEST tömb használata a register_globals on beállításnál.

egyébként én kíváncsi vagyok a 25-ös hozzászólásban említett "elvetemült ötletedre" /és a $_REQUEST tömbbel kapcsolatos véleményedre/.

gex
31

elvetemült ötlet ;)

Hodicska Gergely · 2006. Jún. 2. (P), 09.11
én kíváncsi vagyok a 25-ös hozzászólásban említett "elvetemült ötletedre"

Én meg Gáboréra. ;) Amúgy annyi jutott eszembe, hogy kikapcsolt JS esetén jóval nehezebb CSRF támadást öszehozni, hogy ha a $_POST tömböt használod, mintha a $_REQUEST-et.


Felhő
7

szerintem fontos tudni

Anonymous · 2006. Május. 29. (H), 15.25
pl az oldal elején te post-olt változókat keresel. pl $_POST['username'];

<?php
if(isset($_POST['username']) && $_POST username=='sanyi')
{
print "Szia Sanyi";
}
?>
ha nem post-olt változókat keresel akkor az ilyen oldal így is be fog engedni valami.hu/belepek.php?username=sanyi mert ezt ugye a $_GET['username'] lenne
9

post sem nehéz

Anonymous · 2006. Május. 29. (H), 15.33
egy post kérést sem olyan nehéz meghamisítani:

<form action="valami.hu/belepek.php" method="post">
<input type="text" name="username" value="sanyi">
<input type="submit" value="küld">
</form>
gex
14

És ez miért baj?

Anonymous · 2006. Május. 29. (H), 16.10
Van valami lényege, hogy csak postolni lehessen?

jb
16

-

breakline · 2006. Május. 29. (H), 17.15
A csak POST-olásnak az az értelme, hogy szép legyen az URL, ill. köztes oldalakon nem olyan könnyű belekavarni a dolgokba. Ezzel jön az, h kevesebb adatellenőrzés is kell, mert mondjuk lekérsz egy adatok adatbázisból, aminek a kulcsa 'id', akkor GET esetében ajánlatos betenni:

<?php
if (is_numeric($_GET['id'])) 
 {
indul a mandula...
}
?>
Ez POST-olásnál elhagyható, persze ha nem a felhasználótól kérsz be valami numerikus adatot. De az url-be a felhasználó beírhatja az is, hogy macilaci, aztán meg hibát jelez(het) az adatbázis lekérdezés is. A GET-et igazából olyan adatokra érdemes sztem használni, mint pl. eredmények lapozása, vagy ahol switch-el ellenőrzöd az értéket, mert ott megadhatsz könnyen default értéket is.


üdv
BL
18

POST nem biztonságos

erenon · 2006. Május. 29. (H), 17.28
Aki gonosz, a POST-on azt küld, amit akar. Vannak erre a célra készült böngészők is. Mindent ellenőrizni kell, ami a usertől jön, mégha láthatóan nehezebb feltörni.
22

Típuskonverzió

moikboy · 2006. Május. 29. (H), 19.59
Az ilyen helyzetekre találták ki a...

<?php
@mysql_query("SELECT * FROM `table` WHERE `id`=".(int)$_GET["id"]);
?>
... féle típuskonverziót.
17

funkcio

zsepi · 2006. Május. 29. (H), 17.19
valahol anno olvastam, hogy a GET-es kéréseknek nem illik módosítaniuk semmit, csak riportálnak, míg a POST-os oldalak valók az adatok módosítására.
23

Gondolj bele...

janoszen · 2006. Május. 29. (H), 21.49
... a GET változóval megkülönböztetett URLek különbözőek lesznek. Tehát pl. lehet őket bookmarkolni. Ez jó akkor, ha pl. egy keresés eredményeit listázzuk ki. De rossz akkor, ha valamilyen módosítást hajtunk végre, mert értelemszerűen nem szeretnénk kétszer végrehajtani.
24

Pontosan

attlad · 2006. Május. 29. (H), 22.42
Így van. Lazán kapcsolódóan egy lámer esete:

Googlebot Deletes Pages
http://blog.outer-court.com/archive/2006-03-29-n21.html

De anno a Google Web Accelerator megjelenésekor is előjött a probléma.
28

GET vs POST

toxin · 2006. Jún. 1. (Cs), 10.17
és a gugli

elösször a GET

GET /search?hl=en&q=HTTP&btnG=Google+Search HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020326
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
        text/plain;q=0.8, video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
        text/css,*/*;q=0.1
Accept-Language: en
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive


asztán a POST

POST /search HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020606
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
        text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
        text/css,*/*;q=0.1
Accept-Language: en
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 31

hl=en&q=HTTP&btnG=Google+Search


a különbség 2 sor, megjelent a Content-Type, és A Content-Length vmit az URL kódolt adatok (amire a +2sor vonatkozik)

magyarán szvsz két okból érdemes a POST-ot választani, egyrészt átléphető vele az 1024 karakteres GET-el küldhető adatmennyiség, másrészt az URL nem kerül a location bar-ba (nem lesz szétküldve baráti körben, nem kerül a history-ba stb.) azonban biztonstági okból semmiképp arra ott az SSL
19

White_Pony újra!!!

Anonymous · 2006. Május. 29. (H), 18.26
Köszönöm az eddigi segítséget, most úgy tesztelem a dolgokat, hogy az EasyPHP-ban a PHP beállításainál kikapcsolom a register_globals-t és úgy teszelem localhostból. Nagyjából kezdem kapisgálni, hogy mi a gáz de egy valamit nem értek még. Ti is írjátok ezeket a dolgokat és ugyanezek bent vannak a PHP beállítás komment részeinél is. SZóval a kérdésem a következő:

$_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or $_FILES["foo"]

Mi a külömbség ezek között??? Gondolom nekem egyenlőre a Cookie 100%, hogy nem kell még a kis primitív oldalamhoz. És még azt is megköszönném, hogy valaki csak írjon gyorsan egy példát, hogy lássam, hogy miről is vn szó igazából!

<?php
$valtozo = "Béna vagyok";
echo "$valtozo";
?>

Nahh, hogy pl ezt valaki legyen szíves írja át úgy, hogy ezeket a más formátumú változókkal működjön! Előre is köszönöm és bocsi ha a hozzáértőket idegesítem az amatőr kérdéseimmel :D
21

-

breakline · 2006. Május. 29. (H), 18.48
Egy egyszerű példa, igaz nem a fentiekkel:

<?php
$egyik_tomb=array();
$masik_tomb=array()>

$egyik_tomb['anyag']="parafa";
$masik_tomb['anyag']="acél";

Itt értelemszerűen nem ír ki semmit az
echo $anyag parancs.
?>
A fentiekkel is hasonlóan működik. Én csak azt tudom mondani, szokd meg a $_GET és $_POST tömbökkel való munkát. Megfelelő adatellenőrzés mellett lényegtelen, h a felhasználó manipulálja-e akár a POST adatokat. Ami fontos, azt tárold a szerveren (session-ök), azt nehezebb manipulálni.
A POST és a GET adatátvtieli metódusok (én nem tudok szabatosan fogalmazni, nézz utána), a FILES tömb a formokból feltöltött file-ok adatait tárolja.
A COOKIES a meg sütiket.